1：es集群腦裂問題(不要用外網ip，節點角色不要混用)
原因1：阿里雲服務器，外網有時候不穩定。
解決方案：單獨采購服務器，內網安裝
原因2：master和node節點沒有分開
解決方案：
分角色：master節點(三台)，data節點(隨着數據增加而增加)，client(隨着查詢壓力而增加)節點
Master節點：node.master: true node.data: false
Data節點：node.master: false node.data: true
Client 節點：node.master: false node.data: false
2：es集群名稱的坑(1.4.x版本)
之前在使用1.4版本的時候，這個版本默認是多播協議，可以自動把同一網段的es節點組成一個集群。
所以，在剛開始使用的時候，多種業務部署了多個es集群，結果發現這幾個集群莫名其妙搞到一塊了。
建議：盡量不要使用集群的默認名稱。
不過在2.x的版本中已經默認開啟單播協議，不會自動增加同一網段的節點到一個集群。但是也建議修改一下集群名稱，改完之后，如果使用java api進行操作，則必須設置cluster.name屬性。
3：數據平衡，數據恢復(recover)
假設一個有10個節點的集群。
當重啟集群的時候，在啟動第二個節點的時候，集群之內的兩個節點就開始恢復數據，相互生成副本，當啟動第三個節點的時候，這三個節點又重新對數據進行恢復...........
這樣非常浪費性能，導致在啟動集群的過程當中，做了很多無用功，所以可以設置，當啟動集群中5~6個節點的時候再允許進行數據恢復。
建議設置為集群節點數量的一半以上。
gateway.recover_after_nodes: 5
還有一點：es集群要使用內網ip，否則會出現數據恢復緩慢的現象。
4：定時優化索引片段很重要
開始的時候，沒有對索引片段進行優化，查詢延遲在3S以上，索引優化之后，延遲時間立刻降到1S以內。
5：內存溢出
修改elasticsearch.in.sh腳本
Master節點內存占用不多，CPU稍微高一點。
Data節點內存占用比較多，io操作比較頻繁
Client：CPU和內存占用比較平均
6：集群插入數據報錯
集群狀態為yellow，索引副本數設置為2，但是只有一個節點存活，也就是沒有產生副本。插入數據時報錯。
7：設置jvm鎖住內存時啟動警告
當設置bootstrap.mlockall: true時，啟動es報警告Unknown mlockall error 0，因為linux系統默認能讓進程鎖住的內存為64k。
解決方法：設置為無限制，linux命令：ulimit -l unlimited(立刻生效)
或者修改/etc/security/limits.conf(下一次重啟開始，永久有效)文件
8：elk中，redis中數據堆積嚴重
調整logstash內存，使用批量方式向es中索引數據。
9：橫向擴展es集群，不要縱向擴展
單純增加es節點的內存和CPU不會有很大提升，建議多增加節點。
10：目前es集群部署情況
Master：3台(4 core ,16G內存,500G)
192.168.1.20
192.168.1.21
192.168.1.22
Data：8台(4 core 32G內存,2x1T)
192.168.1.31
192.168.1.32
192.168.1.33
192.168.1.34
192.168.1.35
192.168.1.36
192.168.1.37
192.168.1.38
Client：3台(4 core,32G,500G)
192.168.1.10
192.168.1.11
192.168.1.12
11、后續更新