Netty、Redis、Zookeeper高并发实战

从这本书中更多的是学习了一下netty。认识了下zookeeper。然后里面的im，想去实现，但是确实没有那个精力了。提供的代码保存了下来，以后可以用来抄袭。我的极客精神不见了。

讲的通俗易懂，不过内容偏基础，另外zookeeper跟redis章节感觉是为了书名写的，不比网上内容优质吧

第二章 对于io模型讲解🉐很透彻了

前面的netty部分非常不错，最后几个章节只是粗略介绍了一下API。整体感觉挺不错的。

本书最主要的还是介绍netty，netty部分内容，示例工程im也让这一部分更有质感，脱离理论陷阱，是很不错的netty学习和实战文章，但后面高并发部分不及netty部分丰富，也未涉及原理，权当开拓眼界，查漏补缺，整一个高并发的im工程还没来得及细看，相信看完能有所获。

在实际生产环境中，不同的技术框架是一起使用的，在集群中各司其责，这本书分析了现在流行框架Netty、Redis、Zookeeper的技术原理，以及如何将他们运用到实战之中，重要的部分都有涉及，简单易懂，可以快速地掌握他们的精髓，最后一章的IM系统是这些技术的综合应用，帮助你理解他们在集群中扮演的角色，如何构建一个负载均衡的高性能分布式系统。 Netty：异步的，事件驱动的网络通信框架，基于反应器模式，高性能高并发。 Redis：分布式缓存数据库。 Zookeeper：分布式集群协调服务，通过在内存中构建目录树来存储集群中的资源（节点）信息，可以提供动态节点的命名服务，可以实现分布式锁，可以统计整个集群的在线用户数等等。 第二章的高并发IO底层原理、第四章的Reactor反应器模式，是互联网架构技术的重点内容。 IO读写的基础原理： 调用操作系统的read，是把数据从内核缓冲区复制到进程缓冲区；而write系统调用，是把数据从进程缓冲区复制到内核缓冲区。 书中对同步与异步、阻塞与阻塞的解释是不清楚的，更准确的解释是： 1、同步与异步 同步和异步关注的是消息通信机制。 所谓同步，就是在发出一个调用时，在没有得到结果之前，该调用就不返回。但是一旦调用返回，就得到返回值了。也就是说，调用者主动等待这个调用的结果。 异步则是相反，调用在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在调用发出后，被调用者通过状态、通知来通知调用者，或通过回调函数处理这个调用。 2、阻塞与非阻塞 阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态。 阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。 非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。 NIO三大组件： 1、Bytebuff 缓冲区 2、Channel 通道 3、Selector 选择器 NIO与BIO的区别在于读写是否阻塞的，NiO需要轮询IO事件的就绪状态。 while(true){ ByteBuffer buffer=ByteBuffer.allocate(1024); int r=0; if((r=channel.read(buffer))!=0){ //处理数据 } } 通过选择器Selector，一个线程可以查询多个通道的IO事件的就绪状态，比如服务器监听通道有新连接、传输通道连接成功、传输通道可读、传输通道可写等等。 实现IO多路复用，首先把通道注册到选择器中，然后通过选择器内部的机制，可以查询（select）这些注册的通道是否有已经就绪的IO事件。 Selector的最大优势是，可以用一个线程去监控多个通道，与传统BIO相比，减少了多线程上下文切换的开销。 Nginx、Redis、Netty等中间件技术都是使用反应器技术。 传统BIO模式： 对于每一个新的网络连接都分配给一个线程。每个线程都独自处理自己负责的输入和输出，即Connection Per Thread模式。 缺点是，对应于大量的连接，需要耗费大量的线程资源，对线程资源要求太高。 如何解决Connection Per Thread模式的巨大缺陷呢？使用Reactor反应器模式。用反应器模式对线程的数量进行控制，做到一个线程处理大量的连接。 在反应器模式中，有Reactor反应器和Handler处理器两个重要的组件： （1）Reactor反应器：负责查询IO事件，当检测到一个IO事件，将其发送给相应的Handler处理器去处理。这里的IO事件，对应NIO中选择器监控的通道IO事件。 （2）Handler处理器：与IO事件绑定，负责IO事件的处理。完成真正的连接建立、通道的读取、处理业务逻辑、负责将结果写出到通道等。

一直想搞明白Netty也尝试去看过NIO，Netty相关的书籍，都没坚持下来比较枯燥，作者用通俗易懂的方式帮助读者如何读懂Netty，我认为是最点睛之笔。 1、刚开始从操作系统(内核态)、应用进程（用户态）之间的IO读写，作为基础理论帮助读者认识底层流程是怎么走的。 2、传统IO读写有那些问题，进化到NIO优化了那些问题，以及讲了NIO的核心组件Buffer（缓冲区）、 Channel(管道)、 Selector（选择器）这章节非常重要！非常重要！非常重要！。 3、讲了基于NIO设计出来的Reactor反应堆模式 核心设计思想, 包括单线程与多线程的演进性能方面提升了那些，我感觉Reactor就是Netty的雏形，读者这章节读懂了，Netty的核心思想也基本也有了。也为接下来的章节打下了基础，所以这段基础一定要读懂。非常重要！非常重要！ 4、讲了传统异步回调有什么样的问题，google Guava异步回调以及Netty异步回调 之间的对比与优化，这章节也非常重要Netty框架绝大多数场景使用的都是异步回调。 5、讲了Netty基本使用方式，比较核心的概念就是Pipeline流水线处理。这个点很像Reactor中的attach/attachment组合升级版(读到这里你会发现Netty与Reactor很多共同之处，读起来也简单许多)，包括对Nio byteBuf封装的加强版 也有讲到，其他的读者也可以看看官方案例 API还是讲的很细的。 6、粘包、拆包这块讲的比较细，包括解决方案，包括底层什么原因导致粘包、拆包，理论知识比较值得多读章节。 7、Zookeeper 基础理论存储方式、核心组件大概有讲到包括包括Watcher监听通知，InterProcessMutex重入锁实现分布式锁。Cutator主流客户端。 8、Redis版本就讲的比较基础适合入门使用吧。 9、这本结合所有知识点，做了个开发实践demo，我理解是思路版本的，作者还是很用心帮助大家去深入理解 实战如何使用这些组件，当然让我印象最深刻的、学习更多的还是1~5章节，让我有了基础框架，更好的理解Netty 。 最后：要是作者能够在讲讲select/poll/epoll 之间的缺优点与演进就更好的，因为 高路复用为什么快，还是受限于底层使用什么模型，以及系统句柄数，内存。如果是selelct相对于epoll就要慢，因为底层存储数据结构不一样。

目标 ZooKeeper 是用来做什么的？ 之前没有ZK，为什么会诞生 ZK？ 凭直觉: ZooKeeper 是用于简化分布式应用开发的，对开发者屏蔽一些分布式应用开发过程中的底层细节 ZooKeeper 对外暴露简单的 API，用于支持分布式应用开发 ZooKeeper 在提供上述功能的同时，其还是一个 高性能、高可用、高可靠的分布式集群 上面说这么多，总结一下，ZK 能解决分布式应用开发的问题，ZK 能很好的解决问题。到这一步，疑问就更多了： 分布式应用开发，有哪些常见问题？ZK 是如何屏蔽这些底层细节的？ ZooKeeper 对外暴露了那些 API？这些 API 如何支持分布式应用开发的？这些 API 还能简化吗？API 的语义性怎么样？ ZooKeeper 自身是一个高性能、高可用、高可靠的分布式集群，那有个简单的问题： 高性能是指什么？ZooKeeper 为了达到高性能，做了哪些工作？ 高可用? 高可靠? 为什么有 ZooKeeper 一个应用程序，涉及多个进程协作时，业务逻辑代码中混杂有大量复杂的进程协作逻辑。 上述多进程协作逻辑，有 2 个特点： 处理复杂 处理逻辑可重用 因此，考虑将多进程协作的共性问题拎出，作为基础设施，让 RD 更加专注业务逻辑开发，即： ZooKeeper 就是上述多进程协作基础服务的一种。 ZooKeeper 的特点 ZooKeeper 有几个简单特点： ZooKeeper 的 API：从 文件系统 API 得到的启发，提供简单的 API ZooKeeper 运行在专用服务器上，跟业务逻辑分离，保证了高容错性和可扩展性 ZooKeeper 是存储设施，但特别注意 ZK上存储的数据聚焦为：协作数据（元数据），而不是应用数据，应用数据有自己的存储方案，例如 HDFS 等 ZK 本质上，可以看作一种特殊的 FS 特别说明： 应用数据和元数据，由于使用场景不同，对一致性和持久性的要求有差异， 因此，架构设计、数据治理过程中，应将 2 类数据独立看待、独立存储。 ZooKeeper 的使命 ZK 要解决的核心问题： ZK 目标：简化分布式应用开发中，多进程协作问题。为分布式应用，提供高效、可靠的分布式协调服务（基础服务），例如： 统一的命名服务 分布式锁 进程崩溃检测 Leader 选举 配置管理：配置变更时，及时下发到各个 Client。 一个简单的问题：多进程的协作是什么？尼玛呀，有完没完，啥问题你都有，面对这个掉咋天的脑壳，还是回答一下。 多进程协作，整体分为 2 类： 协作：多进程需要一同处理某些事情，一些进程采取行动是的其他进程能够正常工作，例如：主从结构，M 向 S 分配任务，S 才会执行，否则 S 就保持空闲状态 竞争：两个进程不能同时工作，一个进程必须等待另个进程执行完毕，例如：主从结构，M 节点失效后，很多 S 都想成为 M，这时，就需要互斥锁，只有第一个获得锁的 S 成为 M 特别说明： 不跨网络协作：多进程，可以在同一台物理主机上，同步原语很方便(比如管道、共享内存、消息队列、信号量) 跨网络协作：多进程，分布在不同的物理主机上，ZK 关注这一类 跨网络多进程协作，进程通信，基本思路有 2 个： 消息机制：通过网络，直接信息交换，多消息传递算法，实现同步原语 共享存储：利用外部共享存储，实现多进程协作，要求共享存储提供有序访问，ZK 采用这种方式 真实系统中，跨网络通信，有几个共性问题： 消息延迟：由于网络原因，后发送先到达 处理器性能：由于系统调度原因，消息到达后，延迟处理 时钟偏移：不同物理主机，时钟发生偏移 ZK 精心设计用于屏蔽上述 3 个共性问题，使得这些问题在应用服务层面完全透明化。 ZooKeeper 特性 ZooKeeper 解决的本质问题 分布式系统的一致性问题： 消息传递：延迟性，先发送的消息，不一定先到达； 消息传递：丢失性，发送的消息，可能丢失； 节点崩溃：分布式系统内，任何一个节点都可能崩溃； 在这种情况下，如何保证数据的一致性？ 提案投票：基于投票策略，2PC 选举投票：基于投票策略，投出优先级最高的节点（包含最新数据的节点） Paxos 目标：解决分布式一致性问题，提高分布式系统容错性的一致性算法。 Paxos 本质：基于消息传递的高度容错的一致性算法 ZooKeeper 定位 ZooKeeper 是： 分布式协调服务，高效、可靠，方便应用程序，聚焦业务逻辑开发，而不需要过多关注分布式进程间协作细节。 ZooKeeper 不直接暴露原语，而是，暴露一部分调用方法组成的 API，类似文件系统的 API，支持应用程序实现自己的原语。 ZooKeeper 特性 ZooKeeper 可以保证如下分布式一致性特性： 顺序一致性：同一个 Client 发起的事务请求，严格按照发起顺序执行 原子性：事务请求，要么应用到所有节点，要么一个节点都没有应用 单一视图：Client 无论连接到哪个节点，看到的服务端数据都是一致的（Note：不准确，其实是最终一致性） 可靠性：事务一旦执行成功，状态永久保留 实时性：事务一旦执行成功，Client 并不能立即看到最新数据，但 ZooKeeper 保证最终一致性 ZooKeeper 设计目标 ZooKeeper 致力于提供高性能、高可用、顺序一致性的分布式协调服务，保证数据最终一致性。 目标一：高性能（简单的数据模型） 采用树形结构组织数据节点； 全量数据节点，都存储在内存中； Follower 和 Observer 直接处理非事务请求； 目标二：高可用（构建集群） 半数以上机器存活，服务就能正常运行 自动进行 Leader 选举 目标三：顺序一致性（事务操作的顺序） 每个事务请求，都会转发给 Leader 处理 每个事务，会分配全局唯一的递增id（zxid，64位：epoch + 自增 id） 目标四：最终一致性 通过提议投票方式，保证事务提交的可靠性 提议投票方式，只能保证 Client 收到事务提交成功后，半数以上节点能够看到最新数据 ZooKeeper 出现之前 ZK 出现之前，分布式系统常用两种方式，实现多进程协作： 分布式锁管理器 分布式数据库 ZK 更专注于进程协作，而不提供任何锁接口和通用的存储数据接口。 应用服务器，常见的 2 种需求： Master-Slave Leader 选举：要求提供Master节点选举功能 进程响应跟踪 崩溃检测：要求提供进程存活状态的跟踪 分布式锁：互斥排它锁 ZK 为上述 2 种策略提供了基础 API。 ZooKeeper 不适用的场景： 海量数据存储：ZK 本质是特殊的 FS，但 ZK 用于存储元数据，需要单独存储应用数据

书的内容比较丰富，第九章和十二章的确描述的过于简单，另外十二章只是讲了个思路，没有具体项目的部署信息，如果能够有部署的信息，那这本书的价值就会更高，不过还是要感谢作者的辛苦努力！

在微信读书读的第一本技术书籍。重点看了Netty部分因为之前没有接触过，感觉很不错。比网上的博客和买的某某学院的视频讲的更清晰且容易理解。