《MongoDB存储服务方案设计详解》pdf电子书免费下载
下载方式一：
百度网盘下载地址：https://pan.baidu.com/s/1PUM7-cqymZ_aPz2qE9eVdw
百度网盘密码：1111
下载方式二：
http://ziliaoshare.cn/Download/ae_123539_do_MongoDBCCFWFASJXJ.zip
|
|
作者：empty 出版社：empty |
《MongoDB存储服务方案设计详解》介绍
MongoDB存储服务方案设计
2012-03-14
目录
1.需求分析3
1.1 客车平台和货运平台现有需求3
1.2 现有平台存储服务上存在问题5
2.方案设计7
2.1 存储服务方案设计目标7
2.2 存储方案设计细则7
2.2.1 GPS实时数据存储设计7
2.2.2 拍照数据存储设计8
2.2.3 GPS历史数据查询设计9
2.2.4 GPS数据统计设计10
2.2.5 拍照数据发布和查询设计11
2.3 存储服务业务流程框架设计11
3.方案部署架构设计12
3.1 存储服务（MongoDB）部署架构规划设计12
3.2 存储服务（MongoDB）数据分片规划设计14
3.3 存储服务（MongoDB）实例部署规划设计14
3.4 存储服务（MongoDB）服务器硬件、网络和操作系统规划设计15
3.5 MongoDB版本规划设计16
3.6 存储服务（MongoDB）运营监控规划设计16
4.方案实施17
4.1 实施步骤17
4.2 方案整体实施计划17
附件1: 存储服务表（MongoDB Collection）结构设计18
附件2: 存储服务（MongoDB）对外接口统一定义26
2.1更新类接口26
2.2 查询类接口31
2.3 统计接口39
附件3: 存储服务（MongoDB）安装部署说明41
3.1 安装MongoDB41
3.2 MongoDB分片配置42
3.2.1 分片服务器（sharding）配置42
3.2.2 副本集（Replica Set）配置43
3.2.3 启动并配置三台Config Server43
3.2.4 部署并配置三台Routing Server44
3.2.5 命令行添加分片44
GPS数据存储服务方案设计
1.需求分析
1.1 客车平台和货运平台现有需求
1) 实时数据文件存储类
a. 实时轨迹数据：传统文件方式存储，一条轨迹150B，每天上报8640次，一天大约为1M；
轨迹文件格式说明：
偏移经度: 偏移纬度: GPS时间: GPS 速度: 正北方向夹角: 车辆状态: 报警编码：经度：纬度：海拔：里程：累计油耗：发动机运行总时长：引擎转速（发动机转速）：位置基本信息状态位：报区域/线路报警：冷却液温度：蓄电池电压: 瞬时油耗: 行驶记录仪速度: 机油压力: 大气压力: 发动机扭矩百分比: 车辆信号状态:系统时间 r n
特点：数据频率高，数据量大。
b. 实时报警数据：传统文件方式存储，一条报警100B，每天上报8640次，一天大约为800K；
报警文件格式说明：
报警编码：偏移经度: 偏移纬度：经度：纬度：GPS时间: GPS 速度: 正北方向夹角：累计油耗: 里程: 报区域/线路报警: 海拔：系统时间 r n
特点：数据频率高，数据量大。
c. 驾驶行为事件：传统文件方式存储，一条驾驶行为事件100B，每天上报不固定，根据实际生产环境观察，平均每天最大300K；
特点：数据频率不高，数据量小。
d.发动机负荷率：传统文件方式存储，一条发动机负荷率200B,每天上报360次，一天大约为80K；
特点：数据频率不高，数据量小。
e.拍照数据，图片文件，每天上报数据量不定
特点：数据频率不高，数据量小。
f.盲区补传轨迹文件：轨迹文件统计最大数，这里不做统计；
g.盲区补传报警文件：报警文件统计最大数，这里不做统计；
2) 实时数据传统数据库存储类
Oracle数据库存储
A．存储非法轨迹位置；
B．更新车辆最后位置；
C．存储、更新车辆上下线；
D．存储、更新车辆报警；
MYSQL数据库存储
A．更新车辆最后位置
B．存储、更新车辆报警
3）操作指令传统数据库类
Oracle数据库存储
A.存储、更新下行指令，建议放在MongoDB中，用 Capped Collection来存放。
B.存储车辆多媒体事件
C.存储车辆多媒体信息
D.存储车辆注册，建议放在Oracle数据库中。
E.存储车辆鉴权，建议放在Oracle数据库中，同步到redis中供鉴权服务用。
F.存储车辆注销，建议放在Oracle数据库中。
G.存储车辆事件报告
H.存储车辆信息点播，建议放在Oracle数据库中。
I.存储车辆电子运单，建议放在Oracle数据库中。
J.存储车辆驾驶员信息，建议放在Oracle数据库中，同步到redis，防止二次访问数据库。
K.存储车辆行驶记录仪信息，建议放在Oracle数据库中。
L.存储、更新车辆调度信息，建议放在Oracle数据库中。
M.更新车辆照片信息
N.更新终端参数信息
O.更新路线信息，建议放在Oracle数据库中。
P.更新电子围栏，建议放在Oracle数据库中。
Q.存储、更新终端参数设置，建议放在Oracle数据库中。
R.更新终端版本号，建议放在Oracle数据库中。
S.存储多媒体数据检索
T.存储上行透传信息
U.存储数据压缩透传
V.更新提问应答
MYSQL数据库存储：
A.存储、更新下行指令，建议废弃MySQL，用redis来替代。
B.存储车辆多媒体信息，，建议废弃MySQL，用redis来替代。
4）历史数据查询统计类
A.轨迹回放条件：GPS时间（开始时间、接收时间）、VID；
B.区域查车（当前区域内车辆）条件：车辆类型、车辆速度、是否报警；
C.区域协查（历史区域内车辆）条件：GPS时间；
D.历史报警条件：类型、状态、时间；
1.2 现有平台存储服务上存在问题
1）盲区补传数据分离问题；
2）跨多天历史轨迹查询的问题；
3）报警数据和GPS实时数据分离的问题；
4）区域查车、区域协查的准确性和计算效率问题；
5）报警数据、CAN总线数据统计分析问题，MongoDB提供MapReduce（一个大规模数据并行计算技术，源于google）服务来进行统计分析；
6）拍照数据问题（统一管理，方便访问）；
7）业务流程、数据流程合理性问题；
8）设计质量问题，如下：
3|[16569481][66064567][241][404][200][20120312/172641]|[16569423][66064545][241][415][199][20120312/172642]
9）集群、负载均衡问题；
10）高可用性问题(在线扩容、故障转移)；
11）运营监控问题（存储实例监控）；
2.方案设计
2.1 存储服务方案设计目标
利用MongoDB来一体化解决GPS实时数据（高并发）存储和相关的查询统计业务（如历史轨迹查询），并解决存储服务的长期运营的高可用性问题。
具体包括：
A.解决GPS实时位置信息存储问题（高并发写、高速查询、高速统计分析）；
B.解决GPS报警数据存储问题（高并发写、高速查询、统计分析）；
C.解决司机驾驶行为数据存储问题（高并发写、高速查询、统计分析）；
D.解决拍照数据存储问题（高并发写、自动发布、高速查询）；
E.解决区域查车、区域协查等运算量大的业务统计问题；
F.解决存储服务高可用性问题(如负载均衡、线性扩容、故障转移、灾备恢复、服务监控等)；
最终目标：简化现有平台业务流程，减少故障节点，提高存储服务的高可用性。
2.2 存储方案设计细则
2.2.1 GPS实时数据存储设计
针对GPS实时数据存储，存储服务提供C/C++客户端接口，供通信系统调用，可以直接把GPS数据存放在MongoDB中，而调用者无需关系MongoDB的性能和负载问题。
MongoDB采用目前通用的JSON格式，并提供JSON格式的解析和组装包，支持C/C++、Java、JavaScript、Flex等众多主流开发语言，方便平台各层面来使用。针对MongoDB的数据格式特点，我们把GPS实时数据格式定义为标准JSON格式，其定义如下：
1）GPS实时数据格式定义
详见“附件1“ 和 ”附件2“相关定义。
2）司机驾驶行为数据
司机驾驶行为现有平台的数据格式：驾驶行为类型|[起始位置纬度][起始位置经度][起始位置高度][起始位置速度][起始位置方向][起始位置时间]|[结束位置纬度][结束位置经度][结束位置高度][结束位置速度][结束位置方向][结束位置时间]。
具体数据样例：3|[16569481][66064567][241][404][200][20120312/172641]|[16569423][66064545][241][415][199][20120312/172642]。
3）发动机负荷率数据
格式：无固定格式（BASE64后得到）
具体数据：
-1600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
MongoDB数据库格式定义（JSON）
{
VID : 311,
TS : ISODate( 2012-02-17T14:22:46.777Z ),
DAT :“-1600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000”
}
JSON格式说明：
车辆编号（VID）、时间戳（DS）、负荷数据（DAT）。
2.2.2 拍照数据存储设计
MongoDB提供GridFS特性，用来存储大文件，如图片文件和视频文件。
由通信平台产生的有效拍照图片，可以连同属性信息（如车机ID、时间戳、图片ID、访问路径（http））一起直接存储在MongoDB中，方便前端应用查询。
MongoDB数据库格式定义（JSON）
{
VID : 311,
TS : ISODate( 2012-02-17T14:22:46.777Z ),
“FID”: “file1”,
“HP”: “http://192.168.1.33:270001/file.jpg”,
DAT :“00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000”
}
JSON格式说明：
车辆编号（VID）、时间戳（DS）、文件名（FID）、发布路径（HP）、图片数据（DAT）。
2.2.3 GPS历史数据查询设计
GPS数据查询主要包括：实时数据查询和历史数据查询。
为解决海量GPS数据查询的效率和并发负载问题，在设计时考虑从3各方面来设计和优化：
1）创建数据索引
MongoDB支持对数据进行索引，即可在设计之初就设计好索引，也可在运营期间来对数据的索引进行调整，建议在采用前者。
针对历史轨迹数据的查询需求条件：车机ID，起止时间，可以对“VID”、“TS”字段创建索引，来提高GPS历史轨迹数据的查询效率。
针对报警查询查询需求：起止时间和报警状态，可以对“TS”字段、“VS”字段创建索引。
2）数据读写分离和负载均衡设计
在MongoDB服务部署方案中，我们采用多服务器集群，读写分离的部署架构，即通过部署多个写服务和多个读服务，来解决GPS数据存储的效率和服务可靠性、可扩展性问题。
3）内存数据
MongoDB为提高数据查询的效率，也采用了内存机制，把大量的热点数据放在内存中，来提高数据查询的命中率，我们可以利用这个特性来满足车辆位置查询的需求。
4）GPS数据查询接口设计
a.车辆位置查询接口
提供查询车辆最新位置信息，查询条件为车辆ID，具体实现主要是通过MongoDB的缓存机制来完成。
可提供Java和JavaScript接口，供上层应用调用。
注：此处与实时服务的功能有些重复，建议由实时服务来统一提供。
b.历史轨迹查询接口设计
提供查询每辆车的历史轨迹数据，查询条件为：车辆ID、开始时间、结束时间。返回集应包含去除除Can总线后的数据。
可提供Java和JavaScript接口，供上层应用调用。
注：查询返回的数据集结果尽量简洁，针对每类业务要求的访问，不必要的信息要剔除掉，减少网络压力、提高查询效率。
c．报警数据查询
2.2.4 GPS数据统计设计
1）快照功能
提供查询某个区域内、某段时间、都有哪些车辆，查询条件为。
提供查询某个区域内、某段时间、都有哪些类型的报警车辆。
2）报警统计
可以按报警类别来统计某个时间段内都有哪些报警车辆。
可以统计某辆车在某段时间内的报警次数统计，可按总计、按报警类别来统计。
2.2.5 拍照数据发布和查询设计
通过MongoDB的插件，与Nginx应用服务代理集成，可以直接把存储在MongoDB中的数据发布成Http图片服务，供Web应用层调用。在具体应用中的业务流程如下：
方案说明：
A.解决图片文件储存储分布的问题，可以利用MongoDB把gps数据、图片数据、视频数据等都存储在一起，方便管理和维护；
B.解决图片文件便利访问的问题，如文件的属性，文件的存储，文件的访问路径都作为一条记录存储在MongoDB中，方便上层应用获取；
C.解决图片高效访问的问题，如利用Nginx解决图片资源并发访问的问题，利用Squid/Varnishd缓存服务来解决二次访问MongoDB的问题；
2.3 存储服务业务流程框架设计
MongoDB存储服务提供C++/C#接口、Java接口和JavaScript接口，分别为通讯层、服务层和应用层提供存储服务。
3.方案部署架构设计
3.1 存储服务（MongoDB）部署架构规划设计
为保证MongoDB的高可用性（高并发、高可扩展性、高稳定性），我们采用了Replica Set + Sharding部署架构，这是一种可以水平扩展的模式，在数据量很大时特给力，实际大规模应用一般会采用这种架构去构建MongoDB存储系统。
MongoDB存储服务方案部署架构设计，如下图所示：
MongoDB存储服务集群架构设计
架构图说明：
A.分片cluster：分别在3台服务器(见上图Server-1，Server-3，Server-5)运行一个mongod实例（见上图mongod shard_11，mongod shard_21，mongod shard_31）。
B.副本集：分别在3台服务器（见上图Server-2，Server-4，Server-6）运行一个mongod实例（称为mongod shard12，mongod shard22，mongod shard32），其中：
Server-2的mongod shard12是Server-2的mongod shard_11的副本。
Server-4的mongod shard22是Server-2的mongod shard_21的副本。
Server-2的mongod shard31是Server-2的mongod shard_31的副本。
C.2台服务器，每台服务器（见上图Server-1、Server-3）运行一个mongod实例，作为2个config，其作用是config双机热备。
D.3台服务器，每台服务器（见上图Server-2，Server-4，Server-6）运行一个mongos路由进程，用于客户端连接。
E．线性扩展：可以同时增加2台服务器（见上图Server-5、Server-6），其一个作为分片，另一个作为分片的副本和路由。
备注说明：
1）mongod实例 : 用于存储实际的数据块，实际生产环境中一个shard server角色可由几台服务器组个一个relica set承担，防止主机单点故障。
2）Config Server存储分片集群的的元数据，其中包括在每个mongod实例的基本信息和块信息。每个配置服务器所有块的元数据的副本。通过两次提交来确保在配置服务器信息与块数据的一致性。
3）mongos 可以被看作是一个数据和请求分发的中心，使单一的mongod实例组成互相关联的集群。当接收客户端请求， mongos根据Config Server路由到相应的mongod实例(可能是一组mongod)，处理并返回结果。mongos 进程没有持久状态，在mongos启动时和配置服务器建立连接并获取状态，当配置服务器发生任何变化时，会将之传播到每个mongos 进程。
3.2 存储服务（MongoDB）数据分片规划设计
1）什么叫分片以及分片的作用？
数据分割以及在不同机器存储数据的过程称之为分片。通过在多台机器上分割数据，使得数据库系统能存储更多的数据，和处理更多的负载，在此过程中不需要更多更强大的机器。
MongoDB分片的基本概念是分割集群成更小的块，或是文档。这些分档可以分布于很多的shards，这样每个shard负载总数据集得子集。
举个例子，思考一下。当你从集合选择一个key安装分片时，并使用key分割数据。这个key称为shard key。
假设你有一个联系人的集合。如果我们选择“姓”作为shard key，那么一个分片可以存储“姓”以A-F开头的，下一个分片可以存储“姓”以G-P开头的，最后一个分片存储“姓”以Q-Z开头的。当你添加和删除分片时，MongoDB会重新做数据的负载，这样每个分片会获取一定量的流量和实际量的数据。
所以在决定什么开始分片呢？考虑一下几个因素：
目前的机器的磁盘什么时候用完；
希望比单一的mongod处理速度更快；
希望在内存中保留更多的数据以改善性能；
3.3 存储服务（MongoDB）实例部署规划设计
由于本方案是：规划用4到6台服务器，多个MongoDB（6个mongod实例、2个config实例、3各mongos实例）实例同时运行在这些服务器上，所以在部署前需要先规划好服务器的IP地址、实例的名称、实例的分布（在那台服务器上）、实例的端口等，然后再实施。
本方案的MongoDB数据库实例部署规划如下表所示：
主机 IP服务名及端口
Server_1=“mongodb01”
192.168.5.1（内网）
10.1.1.1（外网）mongod shard_11:27017
mongod config_1:20000
Server_2 = “mongodb02”192.168.5.2（内网）
10.1.1.2（外网）mongod shard_12:27018
mongos_1:30000
Server_3 = “mongodb03”192.168.5.3（内网）
10.1.1.3（外网）mongod shard_21:27017
mongod config_2:20000
Server_4 =“mongodb04”
192.168.5.4（内网）
10.1.1.4（外网）mongod shard_22:27018
mongos_2:30000
Server_5=“mongodb05”
192.168.5.5（内网）
10.1.1.5（外网）mongod shard_31:27017
Server_6=”mongodb06”
192.168.5.6（内网）
10.1.1.6（外网）mongod shard_32:27018
mongos_3:30000
3.4 存储服务（MongoDB）服务器硬件、网络和操作系统规划设计
1）服务器硬件规划要求
服务器内存：至少16G，32G标配，越大越好。
硬盘存储空间：1T以上，非RAID格式，越大越好。注：不建议用磁盘阵列。
服务器CPU：至少4核以上，标配8核，核越多越好CPU。
网卡：千兆网卡，双网卡；
2）网络规划要求
MongoDB服务器集群在一个独立的网段内。
集群服务器用千兆交换机连接。
3）操作系统
RED HAD Linux 64位企业版操作系统，支持中文字符编码。
A．关闭文件系统/分区的atime 选项
Vi /etc/fstab
在对应的分区项后面添加noatime ,nodiratime
LABEL=/1 / ext3 defaults 1 1
LABEL=/data1 /data ext4 defaults,noatime,nodiratime 1 2
B.设置文件句柄４ｋ＋，目前该配置已经集成到启动脚本中。
vi /etc/security/limit.conf
* soft nproc 65536
* hard nproc 65536
* soft nofile 65536
* hard nofile 65536
C.不要使用large vm page （不要使用大内存页选项）
Linux 大内存页参考：http://linuxgazette.net/155/krishnakumar.html
D.用dmesg 查看主机的信息。
E.linux 文件系统的选择
Mongodb 采用预分配的大文件来存储数据,我们推荐:ext3,xfs.
F.Linux系统内核版本
网络上对2.6.33-31 以及2.6.32 的表现持怀疑度， 而强力推荐2.6.36
G．线程堆栈的尺寸
默认的线程堆栈尺寸为10M，调整为1M，已经集成在启动脚本中。
3.5 MongoDB版本规划设计
版本号：2.0.3 for Liunx 64位。
注：偶数的版本是稳定版，奇数是开发版，例如，1.2开头的是稳定版(1.2.0 , 1.2.1 , 1.2.2 等等) ，1.3开头的开发版（1.3.0 , 1.3.1 ,1.3.2 等。
3.6 存储服务（MongoDB）运营监控规划设计
4. 方案实施
4.1 实施步骤
1）方案设计
2）方案评审
3）设计验证
4）结论评估
5）上线实施
4.2 方案整体实施计划
附件1: 存储服务表（MongoDB Collection）结构设计
1.GPS实时数据存储集合（表）结构定义
表名：gps_his_infos。
作用：用于存储车机实时上传GPS数据，并供前端应用查询和统计。
具体表结构信息如下所示：
编号字段名称中文对照别名字段类型是否索引备注
1VID车辆IDA整数是
2TSGPS时间B整数是不包含时区
3LON经度C整数是偏移后的
4LAT纬度D整数是偏移后的
5SP速度E整数
6DIR方向F整数
7ALT海拔高度G整数
8VS车辆状态G整数
9AC报警编码H报警编码子集合
9.1S1紧急报警S1整数
9.2S2超速报警S2整数
9.3S3疲劳驾驶S3整数
9.4S4预警S4整数
9.5S5导航模块故障S5整数
9.6S6导航系统天线未接S6整数
9.7S7导航天线短路S7整数
9.8S8终端主电源欠压S8整数
9.9S9终端主电源掉电S9整数
9.10S10终端显示屏故障S10整数
9.11S11语音模块故障S11整数
9.12S12摄像头故障S12整数
9.13S13当天累计驾驶超时S13整数
9.14S14超时停车S14整数
9.15S15进出区域S15整数
9.16S16进出路线S16整数
9.17S17路线行驶时间不足/过长S17整数
9.18S18路线偏移报警S18整数
9.19S19车辆速度传感器故障S19整数
9.20S20车辆油量异常S20整数
9.21S21车辆被盗S21整数
9.22S22车辆非法点火S22整数
9.23S23车辆非法位移S23整数
9.24S24碰撞侧翻报警S24整数
9.25S25严重故障S25整数
9.26S26制动气压报警S26整数
9.27S27油压报警S27整数
9.28S28水位低报警S28整数
9.29S29制动蹄片磨损报警S29整数
9.30S30空滤堵塞报警S30整数
9.31S31缓速器高温报警信号S31整数
9.32S32仓温报警信号S32整数
9.33S33机滤堵塞信号S33整数
9.34S34燃油堵塞信号S34整数
9.35S35机油温度报警信号S35整数
9.36S36燃油警告S36整数
9.37S37空档滑行告警S37整数
9.38S38超长怠速告警S38整数
9.39S39怠速空调告警S39整数
9.40S40发动机超转告警S40整数
9.41S41急加速报警S41整数
9.42S42急减速报警S42整数
9.43S43门开报警S43整数
9.44S44冷却液温度过高报警S44整数
9.45S45蓄电池电压报警S45整数
9.46S46ABS故障告警S46整数
9.47S47关键点报警S47整数
10LO经度I整数原始经度
11LA纬度J整数原始纬度
12MIL里程L整数
13TOW累计油耗M整数
14ETT发动机运行时长N整数
15ER引擎转速O整数
16LS位置状态位P整数
17ALS区域/线路报警Q字符串
18CT冷却液温度R整数
19SBV蓄电池电压S整数
20IOW瞬时油耗T整数
21RSP记录仪速度U整数
22SD机油压力V整数
23AD大气压力W整数
24ENP发动机扭矩百分比X整数
25DS车辆信号状态Y整数
26ST系统时间Z整数
建议：为节省GPS实时数据的存储空间，我们建议采用英文首字符缩写方式来定义每个字段的名称，当然也可以用a、b、c、d来表示每个字段的名称，这样的好处是节省存储空间，缺点是可读性差，但可以通过相关查询接口函数还原数据项可读性差的问题。
2.GPS报警历史数据存储集合（表）结构定义
表名：alarm_his_infos。
作用：用于车辆报警事件信息的集合（表），包括报警位置、报警时间、报警附加信息、报警处理信息等。
具体表结构信息如下所示：
编号字段名称中文对照别名字段类型是否索引备注
1AID报警IDA整数是
2VID车辆IDB整数是
3VNO车牌号C字符串是
4DID当班司机编号D整数
5STS报警开始时间E1整数是
6SLON经度（起始位置）F1整数偏移后的
7SLAT纬度（起始位置）G1整数偏移后的
8SSP速度（起始位置）H1整数
9SDIR方向（起始位置）I1整数
10SALT海拔（起始位置）J1整数
11SMIL里程（起始位置）K1整数
12STOW累计油耗（起始位置）L1整数
13ETS报警结束时间E2整数是
14ELON经度（结束位置）F2整数偏移后的
15ELAT纬度（结束位置）G2整数偏移后的
16ESP速度（结束位置）H2整数
17EDIR方向（结束位置）I2整数
18EALT海拔（结束位置）J2整数
19EMIL里程（结束位置）K2整数
20ETOW累计油耗（结束位置）L2整数
21AT报警类型编码M整数详见报警编码对照表
22AS报警源N整数1：车载终端，2：企业监控平台，3：政府监管平台，9：其它
23BS基本状态O1整数
24ES扩展状态O2整数
25SAA报警附加信息（开始位置)P1字符串
26EAA报警附加信息（结束位置）P2字符串
27ATS报警时间/系统时间Q整数建议和系统时间合并
28APS报警处理状态R整数是-1：未处理；
0：不作处理；
1：将来处理；
2：处理完毕
29UID报警处理人S整数
30APTS报警处理时间T整数是
31TODO督办状态U整数0：未督办;
1：内部督办;
2：监管平台督办
建议：为节省车辆报警数据的存储空间，我们建议采用英文首字符缩写方式来定义每个字段的名称，当然也可以用a、b、c、d来表示每个字段的名称，这样的好处是节省存储空间，缺点是可读性差，但可以通过相关查询接口函数还原数据项可读性差的问题。
注：
（1）报警类型编码对照表，如下表所示：
报警类型报警编号
紧急报警0
超速报警1
疲劳驾驶2
预警3
导航模块故障4
导航系统天线未接5
导航天线短路6
终端主电源欠压7
终端主电源掉电8
终端显示屏故障9
语音模块故障10
摄像头故障11
当天累计驾驶超时18
超时停车19
进出区域20
进出路线21
路线行驶时间不足/过长22
路线偏移报警23
车辆速度传感器故障24
车辆油量异常25
车辆被盗26
车辆非法点火27
车辆非法位移28
碰撞侧翻报警29
严重故障32
制动气压报警33
油压报警34
水位低报警35
制动蹄片磨损报警36
空滤堵塞报警37
缓速器高温报警信号38
仓温报警信号39
机滤堵塞信号40
燃油堵塞信号41
机油温度报警信号42
燃油警告43
空档滑行告警44
超长怠速告警45
怠速空调告警46
发动机超转告警47
急加速报警48
急减速报警49
门开报警50
冷却液温度过高报警51
蓄电池电压报警52
ABS故障告警53
关键点报警220
（2）报警附加信息编码定义
1.超速报警，格式：位置类型|区域或路段ID
类型： 0：无特定位置；1：圆型区域；2：矩形区域；3：多边形区域；4：路段
当类型为0时，无区域ID或路段ID值
2.进出区域/路段报警附加信息类型 ，格式：位置类型｜区域或线路ID｜方向
类型： 0：无特定位置；1：圆型区域；2：矩形区域；3：多边形区域；4：路线
方向： 0：进，1：出
3.路线行驶时间不足/过长， 格式： 路段ID｜路段行驶时间｜结果
结果： 0：不足，1：过长
3.司机驾驶行为事件存储集合（表）结构定义
表名：driver_action_infos。
作用：用于存储司机驾驶行为数据的表。
具体表结构信息如下所示：
编号字段名称中文对照别名字段类型是否索引备注
1VID车辆IDA整数是
2AID驾驶行为类型B整数是详见下表
3STSGPS时间（起始位置）C整数是不包含时区
4SLON经度（起始位置）D整数偏移后的
5SLAT纬度（起始位置）E整数偏移后的
6SSP速度（起始位置）F整数
7SALT海拔（起始位置）G整数
8SDIR方向（起始位置）H整数
9ETSGPS时间（结束位置）I整数是不包含时区
10ELON经度（结束位置）J整数偏移后的
11ELAT纬度（结束位置）K整数偏移后的
12ESP速度（结束位置）L整数
13EALT海拔高度（结束位置）M整数
14EDIR方向（结束位置）N整数
15ST系统时间O整数
注:驾驶行为类型定义 ：
驾驶行为类型行为编号
加热器工作1
空调工作2
发动机超转3
过长怠速4
超经济区运行5
空档滑行6
怠速空调7
二档起步8
档位不当9
超速10
疲劳驾驶11
4.发动机负荷率存储集合（表）结构定义
表名：engine_load_infos。
作用：用于存储车辆的发动机负荷率数据的集合（表）。
具体表结构信息如下所示：
编号字段名称中文对照别名字段类型是否索引备注
1VID车辆IDA整数是
2TS时间C整数是不包含时区
3DAT负荷数据D字符串
5.拍照数据存储集合（表）结构定义
表名：photo_infos。
作用：用于存储车辆的拍照图片数据的集合（表）。
具体表结构信息如下所示：
编号字段名称中文对照别名字段类型是否索引备注
1VID车辆IDA整数是
2TS拍照时间B整数是不包含时区
3FN文件名C字符串
4HP发布地址D字符串
5DAT图片E二进制对象
6.上下行指令数据集合结构定义
表名：up_down_command_infos。
作用：用于存储车辆的拍照图片数据的集合（表）。
具体表结构信息如下所示：
附件2: 存储服务（MongoDB）对外接口统一定义
存储服务的对外统一接口分为3大类：更新类接口、查询接口和统计类接口。
由于写操作接口跟通信服务紧密相关，所以优先提供C++类型的接口。
查询和统计接口跟上层服务和应用紧密相关，所以提供Java类型的接口和JavaScript接口，这里优先提供Java接口。
2.1更新类接口
1） GPS实时位置数据更新接口
A．GPS实时数据插入操作接口
int insertGPS（BSONObj& gpsData）；
注：BSONObj为MongoDB C++客户端驱动的BSON数据的基本对象。
gpsData参数的声明类型为BSONObj
其具体格式定义如下
{
A : 1175, // 车辆ID
“B” : ISODate( 2012-02-17T14:22:46 )// GPS时间
C : 69838489,// 经度
D : 23946431,// 纬度
E : 59,// 速度
F : 234,// 方向
“G”: 1225,// 海拔高度
VS : {// 车辆状态子类（嵌套）
“s1” ： // 紧急报警
“s2” ： // 超速报警
“s3” ： // 疲劳驾驶
“s4” ： // 预警
“s5” ： // 导航模块故障
“s6” ： // 导航系统天线未接
“s7” ： // 导航天线短路
“s8” ： // 终端主电源欠压
“s9” ： // 终端主电源掉电
“s10” ： // 终端显示屏故障
“s11” ： // 语音模块故障
“s12” ： // 摄像头故障
“s13” ： // 当天累计驾驶超时
“s14” ： // 超时停车
“s15” ： // 进出区域
“s16” ： // 进出路线
“s17” ： // 路线行驶时间不足/过长
“s18” ： // 路线偏移报警
“s19” ： // 车辆速度传感器故障
“s20” ： // 车辆油量异常
“s21” ： // 车辆被盗
“s22” ： // 车辆非法点火
“s23” ： // 车辆非法位移
“s24” ： // 碰撞侧翻报警
“s25” ： // 严重故障
“s26” ： // 制动气压报警
“s27” ： // 油压报警
“s28” ： // 水位低报警
“s29” ： // 制动蹄片磨损报警
“s30” ： // 空滤堵塞报警
“s31” ： // 缓速器高温报警信号
“s32” ： // 仓温报警信号
“s33” ： // 机滤堵塞信号
“s34” ： // 燃油堵塞信号
“s35” ： // 机油温度报警信号
“s36” ： // 燃油警告
“s37” ： // 空档滑行告警
“s38” ： // 超长怠速告警
“s39” ： // 怠速空调告警
“s40” ： // 发动机超转告警
“s41” ： // 急加速报警
“s42” ： // 急减速报警
“s43” ： // 门开报警
“s44” ： // 冷却液温度过高报警
“s45” ： // 蓄电池电压报警
“s47” ： // ABS故障告警
“s47” ： // 关键点报警
}
H :395454,// 经度
I : 1393444,// 纬度
“J” : 1243544,// 海拔高度
“K” : 235679087,// 里程
“L” : 2,// 位置基本信息状态位
“M” : “区域、进”,// 区域/线路报警
“N” : 55,// 行驶记录仪速度
“O” : 2,// 车辆信号状态
“P” : ISODate( 2012-02-17T14:22:46 ),// 系统时间
“CAN” : {// CAN总线数据子类（嵌套）
“c1” : 135,// 累计油耗
“c2” : 135,// 发动机运行总时长
“c3” : 135,// 引擎转速
“c4” : 135,// 冷却液温度
“c5” : 135,// 蓄电池电压
“c6” : 135,// 瞬时油耗
“c7” : 135,// 机油压力
“c8” : 135,// 大气压力
“c9” : 135,// 发动机扭矩百分比
}
}
2）车辆报警数据更新接口
A.车辆报警数据插入操作接口
int insertAlarmData(BSONObj& alarmData)；
alarmData参数的声明类型为BSONObj
其具体格式定义如下：
{
A : 1175, // 车辆ID
“B” : 京B126765 ),// 车牌号码
“C” : 3376,// 当班司机编号
“P1” : {// 报警开始位置信息（子类）
“a1” : ISODate( 2012-02-17T14:22:46 )// 报警开始时间（GPS时间）
a2 : 69838489,// 经度
a3 : 23946431,// 纬度
a4 : 59,// 速度
a5 : 234,// 方向
“a6”: 1225,// 海拔高度
a7 : 234,// 里程
“a8”: 1225,// 油耗
}
“P2” : {// 报警结束位置信息（子类）
“a1” : ISODate( 2012-02-17T14:22:46 )// 报警结束时间（GPS时间）
a2 : 69838489,// 经度
a3 : 23946431,// 纬度
a4 : 59,// 速度
a5 : 234,// 方向
“a6”: 1225,// 海拔高度
a7 : 234,// 里程
“a8”: 1225,// 油耗
}
AC : 395454,// 报警类型编码（索引）
“E” : ISODate( 2012-02-17T14:22:46 ),// 系统时间
F : 1,// 报警源
“G” : 1243544,// 基本状态
“H” : 235679087,// 扩展状态
“AA” : {// 报警附加信息(子集)
“a1” : “开始位置附加信息”// 开始位置
“a2” : “结束位置附加信息”// 结束位置
}
“I” : 2,// 报警处理状态
“J” : “李四”, // 报警处理人
“K” : ISODate( 2012-02-17T14:22:46 ),// 报警处理时间
“L” : 2,// 报警督办状态
}
B．车辆报警数据更新接口
int updateAlarmData(BSONObj& query,BSONObj& alarmData)；
int updateAlarmData(BSONObjBuilder& query);
注：为保证存储服务的性能，强烈建议每条车辆报警数据一次性写入，所以B类接口可以不提供。
3）司机驾驶行为数据写入接口
A．司机驾驶行为数据插入操作接口(C++)
int insertDriveActionData（BSONObj& actionData）；
actionData 参数的声明类型为BSONObj
其具体格式定义如下：
{
A : 7, // 驾驶行为类型
“P1” : {// 开始位置信息（子类）
“a1” : ISODate( 2012-02-17T14:22:46 )// 开始位置时间（GPS时间）
a2 : 69838489,// 经度
a3 : 23946431,// 纬度
a4 : 59,// 速度
a5 : 234,// 方向
“a6”: 1225,// 海拔高度
}
“P2” : {// 结束位置信息（子类）
“a1” : ISODate( 2012-02-17T14:22:46 )// 结束位置时间（GPS时间）
a2 : 69838489,// 经度
a3 : 23946431,// 纬度
a4 : 59,// 速度
a5 : 234,// 方向
“a6”: 1225,// 海拔高度
}
“E” : ISODate( 2012-02-17T14:22:46 ),// 系统时间
}
4） 发动机负荷率数据写入接口
A．发动机负荷率数据插入操作接口(C++)
int insertEngineLoadData（BSONObj& loadData）；
loadData 参数的声明类型为BSONObj
其具体格式定义如下：
{
A : 7, // 车辆ID
“B” : ISODate( 2012-02-17T14:22:46 ), // 系统时间
“C” : “43279843798237482974324234”, // 发动机负荷率数据
}
5） 拍照数据写入接口
A．拍照数据插入操作接口(C++)
int insertPhone(BSONObj& phontData, string phoneName);
int insertPhone(BSONObj& phontData);
phontData 参数的声明类型为BSONObj
其具体格式定义如下：
{
A : 7, // 车辆ID
“B” : ISODate( 2012-02-17T14:22:46 ), // 拍照时间
“C” : “1.jpg”, // 文件名
“D” :”http://192.168.1.5/7-1.jpg” // 图片发布服务器的路径
“E” : “43274827492743827342749872947384874247832783” //图片数据内容
}
2.2 查询类接口
1）历史轨迹回放查询接口
A．Java接口
DBCursor queryGPSDatas(DBObject query);
作用：车辆历史轨迹查询，查询条件为：车辆ID、起始时间、结束时间；
查询条件:
query参数为查询条件，它是DBObject对象，其具体格式如下：
{
VehicleID : 7, // 车辆ID
“BeginDate” : ISODate( 2012-02-17T14:22:46 ), // 开始时间
“EndDate” : ISODate( 2012-02-17T14:22:46 ), // 结束时间
}
查询条件为： VehicleID && （ $gt BeginDate && $lt EndDate）。
返回结果说明：
DBCursor为满足查询条件的结果集对象，其成员对象为DBObject对象。
由于历史轨迹查询的返回结果可能比较大，为减少存储服务压力、减少网络传输，特定义其返回结果集的成员格式为：
其具体格式定义如下
{
A : 1175, // 车辆ID
“B” : ISODate( 2012-02-17T14:22:46 )// GPS时间
C : 69838489,// 经度
D : 23946431,// 纬度
E : 59,// 速度
F : 234,// 方向
“G”: 1225,// 海拔高度
VS : {// 车辆状态子类（嵌套）
“s1” ： // 紧急报警
“s2” ： // 超速报警
“s3” ： // 疲劳驾驶
“s4” ： // 预警
“s5” ： // 导航模块故障
“s6” ： // 导航系统天线未接
“s7” ： // 导航天线短路
“s8” ： // 终端主电源欠压
“s9” ： // 终端主电源掉电
“s10” ： // 终端显示屏故障
“s11” ： // 语音模块故障
“s12” ： // 摄像头故障
“s13” ： // 当天累计驾驶超时
“s14” ： // 超时停车
“s15” ： // 进出区域
“s16” ： // 进出路线
“s17” ： // 路线行驶时间不足/过长
“s18” ： // 路线偏移报警
“s19” ： // 车辆速度传感器故障
“s20” ： // 车辆油量异常
“s21” ： // 车辆被盗
“s22” ： // 车辆非法点火
“s23” ： // 车辆非法位移
“s24” ： // 碰撞侧翻报警
“s25” ： // 严重故障
“s26” ： // 制动气压报警
“s27” ： // 油压报警
“s28” ： // 水位低报警
“s29” ： // 制动蹄片磨损报警
“s30” ： // 空滤堵塞报警
“s31” ： // 缓速器高温报警信号
“s32” ： // 仓温报警信号
“s33” ： // 机滤堵塞信号
“s34” ： // 燃油堵塞信号
“s35” ： // 机油温度报警信号
“s36” ： // 燃油警告
“s37” ： // 空档滑行告警
“s38” ： // 超长怠速告警
“s39” ： // 怠速空调告警
“s40” ： // 发动机超转告警
“s41” ： // 急加速报警
“s42” ： // 急减速报警
“s43” ： // 门开报警
“s44” ： // 冷却液温度过高报警
“s45” ： // 蓄电池电压报警
“s47” ： // ABS故障告警
“s47” ： // 关键点报警
}
“K” : 235679087,// 里程
“L” : 2,// 位置基本信息状态位
“O” : 2,// 车辆信号状态
}
注：
（1） DBObject为MongoDB Java驱动程序BSON格式数据的基本对象。
（2）DBCursor为MongoDB Java驱动程序查询结果集对象，其集合成员对象类型为DBObject。
B．C++接口
int queryHistoryGPSDatas(BSONObj& query, vector BSONObj>& outGPSDatas)；
注：业务层主要提供Java接口，其C++接口可以暂不实现。
2) 车辆报警数据查询接口
A.Java接口
DBCursor queryHistoryAlarmDatas(DBObject query);
作用：查询车辆报警事件数据，查询条件为：车辆ID、起始时间、结束时间、报警状态；
查询条件:
query参数为查询条件，它是DBObject对象，其具体格式如下：
{
VehicleID : 7, // 车辆ID
“BeginDate” : ISODate( 2012-02-17T14:22:46 ), // 开始时间
“EndDate” : ISODate( 2012-02-17T14:22:46 ), // 结束时间
“AlarmState” : {// 车辆报警状态编码（子类）
“s1” ： // 紧急报警
“s2” ： // 超速报警
“s3” ： // 疲劳驾驶
“s4” ： // 预警
“s5” ： // 导航模块故障
“s6” ： // 导航系统天线未接
“s7” ： // 导航天线短路
“s8” ： // 终端主电源欠压
“s9” ： // 终端主电源掉电
“s10” ： // 终端显示屏故障
“s11” ： // 语音模块故障
“s12” ： // 摄像头故障
“s13” ： // 当天累计驾驶超时
“s14” ： // 超时停车
“s15” ： // 进出区域
“s16” ： // 进出路线
“s17” ： // 路线行驶时间不足/过长
“s18” ： // 路线偏移报警
“s19” ： // 车辆速度传感器故障
“s20” ： // 车辆油量异常
“s21” ： // 车辆被盗
“s22” ： // 车辆非法点火
“s23” ： // 车辆非法位移
“s24” ： // 碰撞侧翻报警
“s25” ： // 严重故障
“s26” ： // 制动气压报警
“s27” ： // 油压报警
“s28” ： // 水位低报警
“s29” ： // 制动蹄片磨损报警
“s30” ： // 空滤堵塞报警
“s31” ： // 缓速器高温报警信号
“s32” ： // 仓温报警信号
“s33” ： // 机滤堵塞信号
“s34” ： // 燃油堵塞信号
“s35” ： // 机油温度报警信号
“s36” ： // 燃油警告
“s37” ： // 空档滑行告警
“s38” ： // 超长怠速告警
“s39” ： // 怠速空调告警
“s40” ： // 发动机超转告警
“s41” ： // 急加速报警
“s42” ： // 急减速报警
“s43” ： // 门开报警
“s44” ： // 冷却液温度过高报警
“s45” ： // 蓄电池电压报警
“s47” ： // ABS故障告警
“s47” ： // 关键点报警
}
}
查询条件为： VehicleID && （ $gt BeginDate && $lt EndDate）&& （AlarmState.s1 AlarmState.s4 AlarmState.s9）。
返回结果说明：
DBCursor为满足查询条件的结果集对象，其成员对象为DBObject对象。
由于历史轨迹查询的返回结果可能比较大，为减少存储服务压力、减少网络传输，特定义其返回结果集的成员格式为：
{
A : 1175, // 车辆ID
“B” : 京B126765 ),// 车牌号码
“C” : 3376,// 当班司机编号
“P1” : {// 报警开始位置信息（子类）
“a1” : ISODate( 2012-02-17T14:22:46 )// 报警开始时间（GPS时间）
a2 : 69838489,// 经度
a3 : 23946431,// 纬度
a4 : 59,// 速度
a5 : 234,// 方向
“a6”: 1225,// 海拔高度
a7 : 234,// 里程
“a8”: 1225,// 油耗
}
“P2” : {// 报警结束位置信息（子类）
“a1” : ISODate( 2012-02-17T14:22:46 )// 报警结束时间（GPS时间）
a2 : 69838489,// 经度
a3 : 23946431,// 纬度
a4 : 59,// 速度
a5 : 234,// 方向
“a6”: 1225,// 海拔高度
a7 : 234,// 里程
“a8”: 1225,// 油耗
}
AC : 395454,// 报警类型编码
“E” : ISODate( 2012-02-17T14:22:46 ),// 系统时间
F : 1,// 报警源
“G” : 1243544,// 基本状态
“H” : 235679087,// 扩展状态
“AA” : {// 报警附加信息(子集)
“a1” : “开始位置附加信息”// 开始位置
“a2” : “结束位置附加信息”// 结束位置
}
“I” : 2,// 报警处理状态
“J” : “李四”, // 报警处理人
“K” : ISODate( 2012-02-17T14:22:46 ),// 报警处理时间
“L” : 2,// 报警督办状态
}
B．C++接口
int queryHistoryAlarmDatas(BSONObj& query, vector BSONObj>& outAlarmDatas)；
注：业务层主要提供Java接口，其C++接口可以暂不实现。
3）司机驾驶行为数据查询接口
A．Java接口
DBCursor queryDriveActionDatas queryGPSDatas(DBObject query);
B．C++接口
int queryDriveActionDatas(BSONObj& query, vector BSONObj>& outActionDatas)；
4）发动机负荷率数据查询接口
A．Java接口
DBCursor queryEngineLoadDatas(DBObject query);
B．C++接口
int queryEngineLoadDatas (BSONObj& query, vector BSONObj>& outActionDatas)；
5）拍照数据查询接口
A．Java接口
DBCursor queryPhotoDatas(DBObject query);
作用：查询车辆报警事件数据，查询条件为：车辆ID、起始时间、结束时间、文件名；
查询条件:
query参数为查询条件，它是DBObject对象，其具体格式如下：
{
VehicleID : 7, // 车辆ID
“BeginDate” : ISODate( 2012-02-17T14:22:46 ), // 开始时间
“EndDate” : ISODate( 2012-02-17T14:22:46 ), // 结束时间
}
返回结果说明：
DBCursor为满足查询条件的结果集对象，其成员对象为DBObject对象，其返回结果集的成员格式为：
{
A : 7, // 车辆ID
“B” : ISODate( 2012-02-17T14:22:46 ), // 拍照时间
“C” : “1.jpg”, // 文件名
“D” ：“http://192.168.1.5/7-1.jpg” // 图片发布服务器的路径
}
其中“D“字段的值就是照片的URL，通过其值就可以访问拍照图片了。
4）区域查车接口
A．Java接口
DBCursor queryVehicleForCurrentBound(DBObject query);
需要明确：（1）根据什么条件查；（1）返回哪些信息？
B．C++接口
int queryVehicleForCurrentBound (BSONObj& query, vector BSONObj>& outResultDatas)；
5）区域协查接口
A．Java接口
DBCursor queryVehicleForBound(DBObject query);
需要明确：（1）根据什么条件查；（1）返回哪些信息？
B．C++接口
int queryVehicleForBound (BSONObj& query, vector BSONObj>& outResultDatas)；
2.3 统计接口
1）车辆报警数据统计分析接口
需要明确：（1）根据什么条件统计；（2）都有哪些统计项？
2）司机驾驶行为统计分析接口
需要明确：（1）根据什么条件统计；（2）都有哪些统计项？
附件3: 存储服务（MongoDB）安装部署说明
3.1 安装MongoDB
下载安装mongodb，下载最新文档版，目前最新稳定版为2.0.3;
下载地址：http://www.mongodb.org/downloads，下载列表如下所示。
选择：Linux 64-bit
#下载MongoDB，并安装
cd /root/tools
wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.0.3.tgz
tar zxvf mongodb-linux-x86_64-2.0.3.tgz
mv mongodb-linux-x86_64-2.0.3 /elain/apps/mongodb-linux-x86_64-2.0.3
ln -s /elain/apps/mongodb-linux-x86_64-2.0.3 /elain/apps/mongodb
ln -s /elain/apps/mongodb/bin/* /bin/
#添加用户组
/usr/sbin/groupadd -g 690 mongodb
/usr/sbin/useradd -g mongodb mongodb -u 690 -s /sbin/nologin
各节点hosts文件 添加：
true > /etc/hosts
echo -ne
10.1.1.1 md01
10.1.1.2 md02
10.1.1.3 md03
>>/etc/hosts
3.2 MongoDB分片配置
根据Replica Set+Sharding策略部署mongod。将两个sharding组部署到三台服务器上，每个sharding组有三个Replica Set成员。
详见《3.1存储服务（MongoDB）部署架构规划设计》章节部署设计图。
3.2.1 分片服务器（sharding）配置
1）分片Server-1配置
服务器名：md01 、IP：10.1.1.1(外网)
mkdir -p /data2/mongodb/shard11
mkdir -p /data2/mongodb/shard21
/mongodb/bin/mongod –sha rdsvr --replSet shard1 --port 27017 --dbpath /data2/mongodb/shard11 --oplogSize 100 --logpath /data2/mongodb/shard11.log --logappend --fork --rest
/mongodb/bin/mongod --shardsvr --replSet shard2 --port 27018 --dbpath /data2/mongodb/shard21 --oplogSize 100 --logpath /data2/mongodb/shard21.log --logappend --fork –rest
2）分片Server-2配置
服务器名：md02 、IP：10.1.1.2(外网)
mkdir -p /data2/mongodb/shard12/
mkdir -p /data2/mongodb/shard22/
/mongodb/bin/mongod --shardsvr --replSet shard1 --port 27017 --dbpath /data2/mongodb/shard12 --oplogSize 100 --logpath /data2/mongodb/shard12.log --logappend --fork --rest
/mongodb/bin/mongod --shardsvr --replSet shard2 --port 27018 --dbpath /data2/mongodb/shard22 --oplogSize 100 --logpath /data2/mongodb/shard22.log --logappend --fork –rest
5）分片Server-3配置
服务器名：md02 、IP：10.1.1.3(外网)
mkdir -p /data2/mongodb/shard13/
mkdir -p /data2/mongodb/shard23/
/mongodb/bin/mongod --shardsvr --replSet shard1 --port 27017 --dbpath /data2/mongodb/shard13 --oplogSize 100 --logpath /data2/mongodb/shard13.log --logappend --fork --rest
/mongodb/bin/mongod --shardsvr --replSet shard2 --port 27018 --dbpath /data2/mongodb/shard23 --oplogSize 100 --logpath /data2/mongodb/shard23.log --logappend --fork –rest
3.2.2 副本集（Replica Set）配置
通过命令行初始化两组Replica Set，即副本集-1和副本集-2，通过mongo连接到一个mongod。详见《3.1存储服务（MongoDB）部署架构规划设计》章节部署设计图。
1）配置副本集-1
/mongodb/bin/mongo 10.1.1.1:27017
config = {_id: ‘shard1′, members: [
{_id: 0, host: '10.1.1.1:27017'},
{_id: 1, host: '10.1.1.2:27017'},
{_id: 2, host: '10.1.1.3:27017'}]};
rs.initiate(config);
2）配置副本集-2
/mongodb/bin/mongo 10.1.1.1:27018
config = {_id: ‘shard2′, members: [
{_id: 0, host: ' 10.1.1.1:27018'},
{_id: 1, host: ' 10.1.1.2:27018'},
{_id: 2, host: ' 10.1.1.3:27018'}]};
rs.initiate(config);
3.2.3 启动并配置三台Config Server
详见《3.1存储服务（MongoDB）部署架构规划设计》章节部署设计图。
Server-1、Server-2、Server-3:
mkdir -p /data2/mongodb/config/
/mongodb/bin/mongod --configsvr --dbpath /data2/mongodb/config/ --port 20000 --logpath /data2/mongodb/config1.log --logappend –fork
3.2.4 部署并配置三台Routing Server
详见《3.1存储服务（MongoDB）部署架构规划设计》章节部署设计图。
指定所有的config sever地址参数，chunkSize是分割数据时每块(Chunk)的单位大小。
Server-1、Server-2、Server-3:
/mongodb/bin/mongos --configdb 10.1.1.1:20000, 10.1.1.2:20000, 10.1.1.3:20000 --port 30000 --chunkSize 100 --logpath /data2/mongodb/mongos.log --logappend –fork
3.2.5 命令行添加分片
连接到mongs服务器，并切换到admin。
/mongodb/bin/mongo 172.17.0.121:30000/admin
db.runCommand( { addshard : “shard1/10.1.1.1:27017, 10.1.1.2:27017, 10.1.1.3:27017”,
name:”shard1”,
maxsize:20480,
allowLocal:true } );
db.runCommand( {addshard : “shard2/10.1.1.1:27018, 10.1.1.1:27018, 10.1.1.3:27018”,
name:”shard2”,
maxsize:20480
allowLocal:true} );
db.runCommand( { listshards : 1 } );
如果列出(sharding)了以上二个你加的shards，表示shards已经配置成功。