最近对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的分布式锁在业界内的使用更为广泛。
『以上就是我的想法咯，不知道大家是怎么想的，欢迎指正！』