## 遇到的一些坑和問題
[TOC=3,3]
### SSD性能差
使用SSD做KV存儲時發現磁盤IO非常低。配置成RAID10的性能只有3~6MB/s；配置成RAID0的性能有~130MB/s，系統中沒有發現CPU，MEM，中斷等瓶頸。一臺服務器從RAID1改成RAID0后，性能只有~60MB/s。這說明我們用的SSD盤性能不穩定。
根據以上現象，初步懷疑以下幾點：SSD盤，線上系統用的三星840Pro是消費級硬盤。RAID卡設置，Write back和Write through策略。后來測試驗證，有影響，但不是關鍵。RAID卡類型，線上系統用的是LSI 2008，比較陳舊。
本實驗使用dd順序寫操作簡單測試，嚴格測試需要用FIO等工具。
### 鍵值存儲選型壓測
我們對于存儲選型時嘗試過LevelDB、RocksDB、BeansDB、LMDB、Riak等，最終根據我們的需求選擇了LMDB。
機器：2臺
配置：32核CPU、32GB內存、SSD（(512GB)三星840Pro--> (600GB)Intel 3500 /Intel S3610）
數據：1.7億數據（800多G數據）、大小5~30KB左右
KV存儲引擎：LevelDB、RocksDB、LMDB，每臺啟動2個實例
壓測工具：tcpcopy直接線上導流
壓測用例：隨機寫+隨機讀
LevelDB壓測時，隨機讀+隨機寫會產生抖動（我們的數據出自自己的監控平臺，分鐘級采樣）。
RocksDB是改造自LevelDB，對SSD做了優化，我們壓測時單獨寫或讀，性能非常好，但是讀寫混合時就會因為歸并產生抖動。??
LMDB引擎沒有大的抖動，基本滿足我們的需求。
我們目前一些線上服務器使用的是LMDB，其他一些正在嘗試公司自主研發的CycleDB引擎。
### 數據量大時JIMDB同步不動
Jimdb數據同步時要dump數據，SSD盤容量用了50%以上，dump到同一塊磁盤容量不足。解決方案：
1、一臺物理機掛2塊SSD(512GB)，單掛raid0；啟動8個jimdb實例；這樣每實例差不多125GB左右；目前是掛4塊，raid0；新機房計劃8塊raid10；
2、目前是千兆網卡同步，同步峰值在100MB/s左右；
3、dump和sync數據時是順序讀寫，因此掛一塊SAS盤專門來同步數據；
4、使用文件鎖保證一臺物理機多個實例同時只有一個dump；
5、后續計劃改造為直接內存轉發而不做dump。
### 切換主從
之前存儲架構是一主二從（主機房一主一從，備機房一從）切換到備機房時，只有一個主服務，讀寫壓力大時有抖動，因此我們改造為之前架構圖中的一主三從。
### 分片配置
之前的架構是分片邏輯分散到多個子系統的配置文件中，切換時需要操作很多系統；解決方案：
1、引入Twemproxy中間件，我們使用本地部署的Twemproxy來維護分片邏輯；
2、使用自動部署系統推送配置和重啟應用，重啟之前暫停mq消費保證數據一致性；
3、用unix domain socket減少連接數和端口占用不釋放啟動不了服務的問題。
### 模板元數據存儲HTML
起初不確定Lua做邏輯和渲染模板性能如何，就盡量減少for、if/else之類的邏輯；通過java worker組裝html片段存儲到jimdb，html片段會存儲諸多問題，假設未來變了也是需要全量刷出的，因此存儲的內容最好就是元數據。因此通過線上不斷壓測，最終jimdb只存儲元數據，lua做邏輯和渲染；邏輯代碼在3000行以上；模板代碼1500行以上，其中大量for、if/else，目前渲染性能可以接受。
線上真實流量，整體性能從TP99 53ms降到32ms。
綁定8 CPU測試的，渲染模板的性能可以接受。
### 庫存接口訪問量600w/分鐘
商品詳情頁庫存接口2014年被惡意刷，每分鐘超過600w訪問量，tomcat機器只能定時重啟；因為是詳情頁展示的數據，緩存幾秒鐘是可以接受的，因此開啟nginx proxy cache來解決該問題，開啟后降到正常水平；我們目前正在使用Nginx+Lua架構改造服務，數據過濾、URL重寫等在Nginx層完成，通過URL重寫+一致性哈希負載均衡，不怕隨機URL，一些服務提升了10%+的緩存命中率。
### 微信接口調用量暴增
通過訪問日志發現某IP頻繁抓取；而且按照商品編號遍歷，但是會有一些不存在的編號；解決方案：
1、讀取KV存儲的部分不限流；
2、回源到服務接口的進行請求限流，保證服務質量。
### 開啟Nginx Proxy Cache性能不升反降
開啟Nginx Proxy Cache后，性能下降，而且過一段內存使用率到達98%；解決方案：
1、對于內存占用率高的問題是內核問題，內核使用LRU機制，本身不是問題，不過可以通過修改內核參數
sysctl -w vm.extra_free_kbytes=6436787
sysctl -w vm.vfs_cache_pressure=10000
2、使用Proxy Cache在機械盤上性能差可以通過tmpfs緩存或nginx共享字典緩存元數據，或者使用SSD，我們目前使用內存文件系統。
### 配送至讀服務因依賴太多，響應時間偏慢
配送至服務每天有數十億調用量，響應時間偏慢。解決方案：
1、串行獲取變并發獲取，這樣一些服務可以并發調用，在我們某個系統中能提升一倍多的性能，從原來TP99差不多1s降到500ms以下；
2、預取依賴數據回傳，這種機制還一個好處，比如我們依賴三個下游服務，而這三個服務都需要商品數據，那么我們可以在當前服務中取數據，然后回傳給他們，這樣可以減少下游系統的商品服務調用量，如果沒有傳，那么下游服務再自己查一下。
假設一個讀服務是需要如下數據：
1、數據A ?10ms
2、數據B ?15ms
3、數據C ? 20ms
4、數據D ? 5ms
5、數據E ? 10ms
那么如果串行獲取那么需要：60ms；
而如果數據C依賴數據A和數據B、數據D誰也不依賴、數據E依賴數據C；那么我們可以這樣子來獲取數據：
那么如果并發化獲取那么需要：30ms；能提升一倍的性能。
假設數據E還依賴數據F(5ms)，而數據F是在數據E服務中獲取的，此時就可以考慮在此服務中在取數據A/B/D時預取數據F，那么整體性能就變為了：25ms。
通過這種優化我們服務提升了差不多10ms性能。
如下服務是在抖動時的性能，老服務TP99 211ms，新服務118ms，此處我們主要就是并發調用+超時時間限制，超時直接降級。
### 網絡抖動時，返回502錯誤
Twemproxy配置的timeout時間太長，之前設置為5s，而且沒有分別針對連接、讀、寫設置超時。后來我們減少超時時間，內網設置在150ms以內，當超時時訪問動態服務。
### 機器流量太大
2014年雙11期間，服務器網卡流量到了400Mbps，CPU 30%左右。原因是我們所有壓縮都在接入層完成，因此接入層不再傳入相關請求頭到應用，隨著流量的增大，接入層壓力過大，因此我們把壓縮下方到各個業務應用，添加了相應的請求頭，Nginx GZIP壓縮級別在2~4吞吐量最高；應用服務器流量降了差不多5倍；目前正常情況CPU在4%以下。
