整理的不夠系統，需要之後再完善
1. zookeeper集羣
奇數個節點，原因：投票機制，選舉效率高
2. solrcloud
1. 概念
solrcloud是solr提供的分佈式搜索方案，需要大規模、容錯、分佈式索引和檢索能力時用solrCloud。搜索量很大，搜索請求併發很高時採用。
基於solr和zookeeper的分佈式搜索方案，主要思想是使用zookeeper作爲集羣的配置信息中心。
特色功能：
- 集中式的配置信息
- 自動容錯
- 近實時搜索
- 查詢時自動負載均衡
3. redis-cluster
1. 概念
爲何要搭建Redis集羣。Redis是在內存中保存數據的，而我們的電腦一般內存都不大，這也就意味着Redis不適合存儲大數據，適合存儲大數據的是Hadoop生態系統的Hbase或者是MogoDB。Redis更適合處理高併發，一臺設備的存儲能力是很有限的，但是多臺設備協同合作，就可以讓內存增大很多倍，這就需要用到集羣。
redis 3.0之後版本支持redis-cluster集羣，它是Redis官方提出的解決方案，Redis-Cluster採用無中心結構，每個節點保存數據和整個集羣狀態,每個節點都和其他所有節點連接。其redis-cluster架構圖如下：
客戶端與 redis 節點直連,不需要中間 proxy 層.客戶端不需要連接集羣所有節點連接集羣中任何一個可用節點即可。
所有的 redis 節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬。
2. 分佈式存儲機制-槽
redis-cluster 把所有的物理節點映射到[0-16383]slot 上,cluster 負責維護
Redis 集羣中內置了 16384 個哈希槽，當需要在 Redis 集羣中放置一個 key-value 時，redis 先對 key 使用 crc16 算法算出一個結果，然後把結果對 16384 求餘數，這樣每個key 都會對應一個編號在 0-16383 之間的哈希槽，redis 會根據節點數量大致均等的將哈希槽映射到不同的節點
例如三個節點：槽分佈的值如下：
SERVER1: 0-5460
SERVER2: 5461-10922
SERVER3: 10923-16383
3. 容錯機制-投票
選舉過程是集羣中所有master參與,如果半數以上master節點與故障節點通信超過(cluster-node-timeout),認爲該節點故障，自動觸發故障轉移操作. 故障節點對應的從節點自動升級爲主節點
什麼時候整個集羣不可用
如果集羣任意master掛掉,且當前master沒有slave.集羣進入fail狀態,也可以理解成集羣的slot映射[0-16383]不完成時進入fail狀態
其他概念
1. 反向代理
Reverse Proxy，以代理服務器來接收Internet上的連接請求，然後將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給Internet上請求鏈接的客戶端，此時代理服務器對外表現爲一個反向代理服務器。
nginx主機修改nginx配置文件
upstream pinyougou-portal {
server 192.168.25.141:8080;
}
server {
listen 80;
server_name www.pinyougou.com;
location / {
proxy_pass http://pinyougou-portal;
index index.html;
}
}
2. 負載均衡
web工程 由nginx做反向代理實現負載均衡
服務工程 由zookeeper負責負載均衡
nginx配置
upstream pinyougou-portal {
server 192.168.25.141:8080;
server 192.168.25.141:8081;
server 192.168.25.141:8082;
}
server {
listen 80;
server_name www.pinyougou.com;
location / {
proxy_pass http://pinyougou-portal;
index index.html;
}
}
3. 高可用
nginx壓力很大，需要建立備份機，主機和備份機都運行高可用監控程序來監控對方的運行狀況。
keepalived就是集羣管理中保證集羣高可用的服務軟件，防止單點故障。