為什麼說中小公司自建Redis是一件不太靠譜的事情？

上段時間，和資料庫領域的一些朋友交流，他告訴雲栖社群，xx廠商自建redis出問題了，并表示最近不少自建redis的中小公司也都陸續出問題。

對于為什麼會出現這樣現象，雲栖社群記者就此采訪了阿裡雲資料庫進階技術專家子嘉，他談了問題的根源——自建redis的缺點：

可靠性低：如果資料走雲盤做高可靠存儲容易受網絡波動幹擾，如果不走雲盤當機資料易丢失，自建多副本運維很複雜，而且redis本身的斷網導緻的全量同步機制對網絡和運維的要求極高；

可用性低：自建單副本無法保證可用性，多副本對心跳檢查和鍊路切換要求極高，傳統的sentinel有很多缺陷，在執行複雜的keys flushdb等指令時很容易造成誤切和雪崩；

諸多限制：自建叢集方案如redis cluster，codis也有諸多限制，redis cluster需要smart client和非常專業的運維能力，codis的zk部署也相對比較重，而且為了容災也要去做副本的ha，而目前的ha和上述sentinel有同樣的問題；

安全性：自建redis容易受到安全攻擊，比如config set漏洞問題，lua安全漏洞等問題，當出現故障時也無法得到有效地救援和解決；

産品本身：從産品上，自建redis無法實作彈性擴縮容，或者過程非常複雜，并且在擴縮容的過程中也非常容易出問題。

子嘉指出，而最根本的問題是如果要達到上述的可靠性、可用性與安全性，客戶需要在看得見的成本之外付出更多的運維成本，而且還需要組建一直完備的技術團隊。

他認為，對可靠性、可用性、安全性、資源彈性有訴求的産品，選用雲redis則是不二選擇，尤其是阿裡雲redis，因為它有以下優點：

雲redis采用兩副本+備份的方式保證資料可靠性，本地ssd磁盤保證穩定性和性能，還有一整套的運維體系，針對原生redis的缺點在核心上做了很多改進；

雲redis通過優化核心+自主研發ha來解決複雜指令逾時問題，保證不會誤切換，而且當主節點有故障發生時，會有秒級鍊路切換，最大保證可用性；

雲redis自主研發的叢集模式相容所有版本開源用戶端，對client沒有要求，接入方式和主從版一樣，支援的指令也要比上述兩個版本多，對于大家比較關心的成本問題，阿裡雲redis也在推出小記憶體大qps來解決

雲redis自主研發版本經過阿裡内部安全滲透測試，而且在出問題時也會有一直專業的核心團隊7*24及時救援和服務