在對mongoDB的操作有了一定基礎后，終於可以扯扯HA和架構這兩個高大上的概念了。在這之前當然還得弄清楚mongoDB的Key feature：Sharding。
1. Sharding
Shard從邏輯上來說就是整個數據的一個子集，從物理來說就是管理這一子集的服務器。一個分片可以包含多台服務器。若一個分片包含多台服務器則每台服務器都有一份完全相同的數據子集副本（Replica set）。
分片是MongoDB強調的一個Feature。分片的目的就在於完成自動化集群運維。mongoDB cluster需要三種角色，Sharding server /Config Server /Route。
2. HA
HA是個大話題，從一個簡單系統的部署為點開始談談吧。
如圖所示，架構上一個mongoDB集群需要上述三種角色，這三種角色分別對應三個進程：mongos，shardsvr mongod和config mongod。
figure1
Step1：啟動shard server實例1與實例2
| >mongod --shardsvr --port 20000 --dbpath=/data/shared/s0 --fork --logpath=/data/shard/log/s0.log --directoryperdb
>mongod --shardsvr --port 20001 --dbpath=/data/shared/s1 --fork --logpath=/data/shard/log/s1.log --directoryperdb |
Step2：啟動Config Server實例
| >mongod --configsvr --port 30000 --dbpath=/data/shared/config --fork --logpath=/data/shard/log/config.log --directoryperdb |
Step3：啟動Route Server實例
| >mongos --port 40000 --configdb localhost:30000 --fork --logpath=/data/shared/log/route.log --chunkSize 64 |
其中chunkSize指定chunk大小，單位為MB，默認大小為200MB。
MongoDB auto-sharding解決了海量存儲和動態擴容問題，然而以上離真正的生產環境HA方案還差的遠。下面更進一步，搭建Replica Sets + Sharding解決方案，設計案例。
Case1：
- Shard：使用Replica Sets，確保每個數據節點都具有備份、自動容錯轉移、自動恢復能力。
- Config Server：使用3個配置服務器，確保元數據完整性，存放key的對應關系。
- Route Server：使用方法3個路由進程，實現負載均衡，提高客戶端的接入性能及並發度。
- 搭建上述集群完畢后，可以加入memcached服務器，將高訪問量的數據緩存在內存中，避免高頻度的磁盤I/O，從而進一步提升性能。
表1 小型使用案例舉例
| Host |
IP |
服務及端口分配 |
| Server A |
192.168.3.231 |
Mongod shard1_1: 27017 Mongod shard2_1: 27018 Mongod config1: 20000 Mongos1: 30000 |
| Server B |
192.168.3.232 |
Mongod shard1_2: 27017 Mongod shard2_2: 27018 Mongod config2: 20000 Mongos2: 30000 |
| Server C |
192.168.3.233 |
Mongod shard1_3: 27017 Mongod shard2_3: 27018 Mongod config3: 20000 Mongos3: 30000 |
當然實際使用環境中的集群系統肯定更復雜，HA不是一個簡單的話題，更包括容災備份等問題，本人也沒有什么實踐經驗，因此也只能說說一些理論的東西，希望與大家共同交流學習。
按照慣例，要圖文並茂，今天畫的是坂田銀時，相信園子里喜歡銀魂的人不在少數，之前看到許多朋友都是銀魂的頭像。在孤獨地編程、寫作時，《銀魂》似乎支撐了很多人，毒舌吐槽的背后是一個個簡單而又平凡的人生真諦，溫暖人心。有興趣的可以看看新世相的這篇文章《閣下想要保護的東西已經是一片虛無》。
全棧路上，沒有歸途。