前言
最近對Redis和Zookeeper的使用場景有了新的理解，在此記錄下，
對于Redis和ZK的基本用法和原理，我想就沒有必要再多介紹了，畢竟網上的教程比比皆是，
在此，有兩點想法，希望能對大家在Redis和Zookeeper的學習使用上有所幫助，有不同想法，歡迎討論喲，
從官網的介紹的角度來看
Redis和Zookeeper的使用異同點看過很多，但是最終在我的思維里也一直沒有一個清晰的定論，大概就是模糊的概念，最近看了下Redis和Zookeeper的官網，兩者同樣作為key-value組件，應用場景確有著很大的不同，
Zookeeper(https://zookeeper.apache.org/)
官網介紹的第一句話對Zookeeper的定義
ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
153/5000
ZooKeeper是一個集中的服務，用于維護配置資訊、命名、提供分布式同步、提供分組服務等
Redis(https://redis.io/)
Redis官網的介紹
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker.
Redis和Zookeeper一樣基于記憶體，可以用作資料庫、快取、訊息中間件
從這個兩個分布式記憶體型組件的官網介紹可以清晰的看出兩者的異同點，
我覺得最重要的一點是Redis專注于資料本身的存盤，而Zookeeper更專注于分布式組件的協調，和配置，
從WAL設計的角度來看
先貼兩篇WAL的介紹，很詳盡，不太懂的xdm可以先去看看，
https://zhuanlan.zhihu.com/p/228335203
https://zhuanlan.zhihu.com/p/137512843
WAL：預寫式日志，利用磁盤的順序IO的特性，提高性能
WAL 機制會 enable fsync，如果出于系統吞吐量的角度，那么 WAL 機制可以選擇 disable fsync，
ZooKeeper通過 forceSync 配置來控制是否開啟 WAL 的 fsync，默認情況下為 yes，即每次發生更新，強制同步刷盤，保證了分布式系統的可靠性；當設定為no時，ZooKeeper將不會強制同步事務更新日志到磁盤，官網上將這個選項描述為不安全的選線，
Redis 的 AOF（append only file）模式基于 WAL 機制實作，默認情況下每間隔 1 秒執行一次 fsync 系統呼叫實作更新操作的持久化，
參考這篇文章 http://oldblog.antirez.com/post/redis-persistence-demystified.html
可以看到Redis AOF的默認刷盤策略配置 appendfsync everysec 為每秒一次；這意味著極端情況下，Redis會丟失資料，
通過這兩個組件的設計初衷上來看，ZooKeeper 比 Redis 提供了更可靠的持久性保證，但從另一方面來看Redis 也提供了更高的系統吞吐量，
總結
對于常見的業務場景分布式鎖的實作，Redis和Zookeeper都是很好的選擇，從上面的分析看來，我認為Zookeeper的設計初衷更適合，but就我實際使用的情況來說，幾乎每個專案，Redis的使用必不可少，Zookeeper倒是很少見，
假如你的系統配置中心已經選用了nacos，Apollo這種，只是為了分布式鎖的實作，引入一個新的組件，對于系統的穩定性來說肯定是不太合理的，何況Redis的分布式鎖在業界內的使用更為廣泛，
『以上就是我的想法咯，不知道大家是怎么想的，歡迎指正！』
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/423974.html
標籤：其他