1.redis源码解读（一）：事件驱动的看源看io模型，为什么，码何是源码什么，怎么做
2.响应式编程入门之 Project Reactor
3.FREE SOLO - 自己动手实现Raft - 10 - libuv源码分析与调试-1
4.Reactive Spring实战 -- 理解Reactor的看源看设计与实现
5.第6章 Reactor Netty中的消息处理逻辑 01
6.Reactor-Netty基本抽象类介绍
redis源码解读（一）：事件驱动的io模型，为什么，码何是源码python eval函数源码什么，怎么做
Redis作为一个高性能的看源看内存数据库，因其出色的码何读写性能和丰富的数据结构支持，已成为互联网应用不可或缺的源码中间件之一。阅读其源码，看源看可以了解其内部针对高性能和分布式做的码何种种设计，包括但不限于reactor模型（单线程处理大量网络连接），源码定时任务的看源看实现（面试常问），分布式CAP BASE理论的码何实际应用，高效的源码数据结构的实现，其次还能够通过大神的代码学习C语言的编码风格和技巧，让自己的代码更加优雅。
下面进入正题：为什么需要事件驱动的io模型
我们可以简单地将一个服务端程序拆成三部分，接受请求->处理请求->返回结果，其中接收请求和处理请求便是我们常说的网络io。那么网络io如何实现呢，首先我们介绍最基础的io模型，同步阻塞式io，也是很多同学在学校所学的“网络编程”。
使用同步阻塞式io的单线程服务端程序处理请求大致有以下几个步骤
其中3,4步都有可能使线程阻塞（6也会可能阻塞，这里先不讨论）
在第3步，如果没有客户端请求和服务端建立连接，那么服务端线程将会阻塞。如果redis采用这种io模型，那主线程就无法执行一些定时任务，比如过期key的清理，持久化操作，集群操作等。
在第4步，如果客户端已经建立连接但是没有发送数据，服务端线程会阻塞。若说第3步所提到的定时任务还可以通过多开两个线程来实现，那么第4步的阻塞就是硬伤了，如果一个客户端建立了连接但是头像网网站源码一直不发送数据，服务端便会崩溃，无法处理其他任何请求。所以同步阻塞式io肯定是不能满足互联网领域高并发的需求的。
下面给出一个阻塞式io的服务端程序示例：
刚才提到，阻塞式io的主要问题是，调用recv接收客户端请求时会导致线程阻塞，无法处理其他客户端请求。那么我们不难想到，既然调用recv会使线程阻塞，那么我们多开几个几个线程不就好了，让那些没有阻塞的线程去处理其他客户端的请求。
我们将阻塞式io处理请求的步骤改造下：
改造后，我们用一个线程去做accept，也就是获取已经建立的连接，我们称这个线程为主线程。然后获取到的每个连接开一个新的线程去处理，这样就能够将阻塞的部分放到新的线程，达到不阻塞主线程的目的，主线程仍然可以继续接收其他客户端的连接并开新的线程去处理。这个方案对高并发服务器来说是一个可行的方案，此外我们还可以使用线程池等手段来继续优化，减少线程建立和销毁的开销。
将阻塞式io改为多线程io：
我们刚才提到多线程可以解决并发问题，然而redis6.0之前使用的是单线程来处理，之所以用单线程，官方给的答复是redis的瓶颈不在cpu，既然不在cpu那么用单线程可以降低系统的复杂度，避免线程同步等问题。如何在一个线程中非阻塞地处理多个socket，进而实现多个客户端的并发处理呢，那就要借助io多路复用了。
io多路复用是操作系统提供的另一种io机制，这种机制可以实现在一个线程中监控多个socket，返回可读或可写的socket，当一个socket可读或可写时再去操作它，这样就避免了对某个socket的阻塞等待。
将多线程io改为io多路复用：
什么是事件驱动的io模型（Reactor）
这里只讨论redis用到的单线程Reactor模型
事件驱动的io模型并不是一个具体的调用，而是货币众筹源码高并发服务器的一种抽象的编程模式。
在Reactor模型中，有三种事件：
与这三种事件对应的，有三种handler，负责处理对应的事件。我们在一个主循环中不断判断是否有事件到来（一般通过io多路复用获取事件），有事件到来就调用对应的handler去处理时间。
听着玄乎，实际上也就这一张图：
事件驱动的io模型在redis中的实现
以下提及的源码版本为 5.0.8
文字的苍白的，建议参照本文最后的方法下载代码，自己调试下
整体框架
redis-server的main方法在 src/server.c 最后，在main方法中，首先进行一系列的初始化操作，最后进入进入Reactor模型的主循环中：
主循环在aeMain函数中，aeMain函数传入的参数 server.el ，是一个 aeEventLoop 类型的全局变量，保存了主循环的一些状态信息，包括需要处理的读写事件、时间事件列表，epoll相关信息，回调函数等。
aeMain函数中，我们可以看到当 eventLoop->stop 标志位为0时，while循环中的内容会被重复执行，每次循环首先会调用beforesleep回调函数，然后处理时间。beforesleep函数在main函数中被注册，会进行集群状态更新、AOF落盘等任务。
之所以叫beforesleep，是因为aeProcessEvents函数中包含了获取事件和处理事件的逻辑，其中获取读写事件时通过epoll_wait实现，会将线程阻塞。
在aeProcessEvents函数中，处理读写事件和时间事件，参数flags定义了需要处理的事件类型，我们可以暂时忽略这个参数，认为读写时间都需要处理。
aeProcessEvents函数的药品溯源码查询逻辑可以分为三个部分，首先获取距离最近的时间事件，这一步的目的是为了确定epoll_wait的超时时间，并不是实际处理时间事件。
第二个部分为获取读写事件并处理，首先调用epoll_wait，获取需要处理的读写事件，超时时间为第一步确定的时间，也就是说，如果在超时时间内有读写事件到来，那么处理读写时间，如果没有读写时间就阻塞到下一个时间事件到来，去处理时间事件。
第三个部分为处理时间事件。
事件注册与获取
上面我们讲了整体框架，了解了主循环的大致流程。接下来我们来看其中的细节，首先是读写事件的注册与获取。
redis将读、写、连接事件用结构aeFileEvent表示，因为这些事件都是通过epoll_wait获取的。
事件的具体类型通过mask标志位来区分。aeFileEvent还保存了事件处理的回调函数指针（rfileProc、wfileProc）和需要读写的数据指针（clientData）。
既然读写事件是通过epoll io多路复用实现，那么就避不开epoll的三部曲 epoll_create epoll_ctrl epoll_wait，接下来我们看下redis对epoll接口的封装。
我们之前提到aeMain函数的参数是一个 aeEventLoop 类型的全局变量，aeEventLoop中保存了epoll文件描述符和epoll事件。在aeApiCreate函数（src/ae_epoll.c）中，会调用epoll_create来创建初始化epoll文件描述符和epoll事件，调用关系为 main -> initServer -> aeCreateEventLoop -> aeApiCreate
调用epoll_create创建epoll后，就可以添加需要监控的文件描述符了，需要监控的情形有三个，一是监控新的客户端连接连接请求，二是监控客户端发送指令，也就是读事件，三是箱体标公式源码监控客户端写事件，也就是处理完了请求写回结果。
这三种情形在redis中被抽象为文件事件，文件事件通过函数aeCreateFileEvent（src/ae.c）添加，添加一个文件事件主要包含三个步骤，通过epoll_ctl添加监控的文件描述符，指定回调函数和指定读写缓冲区。
最后是通过epoll_wait来获取事件，上文我们提到，在每次主循环中，首先根据最近到达的时间事件来计算epoll_wait的超时时间，然后调用epoll_wait获取事件，再处理事件，其中获取事件在函数aeApiPoll（src/ae_epoll.c）中。
获取到事件后，主循环中会逐个调用事件的回调函数来处理事件。
读写事件的实现
写累了，有空补上……
如何使用vscode调试redis源码
编译出二进制程序
这一步有可能报错：
jemalloc是内存分配的一种更高效的实现，用于代替libc的默认实现。这里报错找不到jemalloc，我们只需要将其替换成libc默认实现就好：
如果报错：
我们可以在src目录找到一个脚本名为mkreleasehdr.sh，其中包含创建release.h的逻辑，将报错信息网上翻可以发现有一行：
看来是这个脚本没有执行权限，导致release.h没有成功创建，我们需要给这个脚本添加执行权限然后重新编译：
2. 创建调试配置（vscode）
创建文件 .vscode/launch.json，并填入以下内容：
然后就可以进入调试页面打断点调试了，main函数在 src/server.c
响应式编程入门之 Project Reactor
本文旨在为读者提供对响应式编程及其核心库——Reactor的入门理解。在介绍前，我们先回顾一下非阻塞IO编程的基础，理解为何在Spring MVC中引入了WebFlux以及Reactor。Reactor是基于Java 8函数式API，集成CompletableFuture、Stream和Duration，它提供了Flux和Mono等异步序列API，并实现了Reactive Streams规范，特别适合构建微服务架构中的响应式系统。
在非阻塞IO编程中，比如调用远程服务时，我们通常通过回调函数来处理数据可用情况。然而，当回调逻辑复杂时，代码往往难以阅读。响应式编程通过简化这种逻辑，提供了更简洁的实现方式。它将传统命令式编程抽象为一系列API，更适合非阻塞IO环境。尽管响应式编程在非阻塞IO框架中广泛应用，如Vertx和WebFlux，但这并不意味着非阻塞IO编程只能依赖响应式编程。
Reactor作为响应式编程的基础，实现了Java响应式编程规范，理解其内部工作原理有助于深入掌握其API。Reactor的核心接口展示了其运作机制，包括数据发布和订阅流程。在实际应用中，Publisher和Subscription共同作用，通过调用Subscriber的onNext、onComplete和onError方法来实现数据流转。
响应式编程思想可类比为一条流水线，Publisher定义了数据生产过程，Operators对数据进行解析、校验和转换等操作，最终流转到Subscriber。这种设计使得系统在未被订阅之前保持静默，直至实际使用时才启动。
Reactor中的Operator作为连接上下游的关键组件，实现了数据的转换和处理。例如，map操作符通过改变数据值来实现数据转换。实际实现虽然复杂且严谨，但遵循了相同的设计理念。
学习Reactor的关键在于理解核心接口以及实践API。首先理解响应式编程的基本概念和Reactor如何实现这些概念。接下来，深入阅读官方文档并进行代码实践。追踪源码时，关注subscribe方法和Subscription的作用，以及Subscriber中的onNext、onComplete和onError方法的实现。
总之，通过本文的学习，读者应能对响应式编程和Reactor有初步的了解，并掌握学习Reactor的方法和途径。尽管本文未详细探讨Reactor的每个细节，但它为深入探索提供了基础。欢迎读者通过实践和阅读源码进一步深入理解这一强大且灵活的编程范式。
FREE SOLO - 自己动手实现Raft - - libuv源码分析与调试-1
了解EventLoop这一核心概念，就是“Reactor模型”的主体框架。Reactor模型是一种程序设计模式，其本质在于如何对外界各种刺激做出反应，利用单一或者多个线程，处理各类外部事件，如网络数据包接收、定时器超时等，根据不同事件注册相应的回调函数。
以“状态机思维”分析libuv源码，为后续开发奠定基础。状态机思想提供了一种简洁高效的方式来描述程序的工作流程。在libuv中，主要有两种核心数据结构：Handle与Request。Handle代表常驻内存提供服务的数据结构，如uv_tcp_s，表示TcpServer，不断对外提供服务，同样可以作为TcpClient。Request则代表一次请求，如uv_req_s，其生命周期与请求处理过程相同，不会驻留在内存中。请求被处理后，该数据结构随即释放。
libuv能够处理多种不同事件，常见的几种包括：网络事件、文件系统事件、信号事件、异步操作完成事件等。未来，我们将深入解析这些核心事件的相关源代码。
Reactive Spring实战 -- 理解Reactor的设计与实现
Reactor是Spring提供的非阻塞式响应式编程框架，实现了Reactive Streams规范。它提供了可组合的异步序列API，包括用于多个元素的Flux和用于零到一个元素的Mono。
Reactor Netty项目还支持非阻塞式网络通信，非常适合微服务架构，为HTTP（包括Websockets），TCP和UDP提供了响应式编程基础。本文将通过实例展示和源码阅读，深入分析Reactor的核心设计与实现机制。
Reactor源码基于版本3.3。
响应式编程是一个专注于数据流和变化传递的异步编程范式，允许使用编程语言表示静态或动态数据流。
Reactor中，发布者（Publisher）负责生产数据，订阅者（Subscriber）负责处理和消费数据。创建发布者和订阅者后，通过建立订阅关系，发布者开始生产数据并传递给订阅者。
Flux和Mono是两种发布者类型，分别用于生产多个数据元素和单个数据元素。例如，Flux.range和fromArray等静态方法会返回Flux子类。
Reactor中关键方法包括Publisher#subscribe和Flux#subscribe。订阅者在onSubscribe方法中接收订阅关系，然后通过Subscription#request方法向发布者请求数据。
RangeSubscription#request、Subscriber#onNext和CoreSubscriber的内部逻辑展示了数据流转的过程。Flux子类的subscribe方法创建Subscription，将操作符逻辑转移到Subscriber端。
操作符方法，如skip、distinct、sort和filter，是Reactor的核心，用于处理和组合数据流。例如，myHandler作为订阅者，可以处理生成的Flux子类序列。
Reactor支持push和pull模式。pull模式通过Flux#generate和Sink缓存数据，而push模式则通过Flux#create，允许多线程同时推送数据。
Reactor提供线程与调度器支持，例如parallel、single、boundedElastic和parallel。这些调度器允许在不同线程环境下执行操作。
Reactor中的publishOn和subscribeOn操作符方法用于切换操作上下文，分别影响后续操作和整个链路的线程执行环境。
流量控制是响应式编程中的重要概念，FluxSink.OverflowStrategy定义了在数据生产速度超过消费速度时的策略，如忽略、错误或缓存数据。
Reactor通过实例和源码展示了响应式编程的概念和实现机制，以及如何在实际应用中使用。通过WebFlux和AsyncRestTemplate的比较，将揭示响应式编程带来的优势。
第6章 Reactor Netty中的消息处理逻辑
在深入探讨Reactor Netty中的消息处理逻辑时，我们首先回顾了ChannelOperationsHandler作为WebFlux与Netty之间的重要桥梁，以及如何通过Channel生命周期的核心功能实现对Netty客户端与服务器端连接的封装。关注服务器端层面上的浏览器通过HTTP请求访问应用程序所涉及的Channel及其消息传递机制，这一章旨在逐步揭示其中的组织细节。
在理解Reactor Netty中如何利用ChannelOperationsHandler进行通信的基础上，我们重点分析了ConnectionObserver与channelOperation的相互配合。特别地，我们探讨了ConnectionObserver如何在服务器端通过其onStateChange方法，根据不同的ConnectionObserver.State状态对Channel执行相应操作。以PooledConnectionProvider#acquire的源码为例，展示了如何在获取Channel时预先配置ConnectionObserver和channelOperationFactory，进而根据应用场景进行灵活的定制与配置。
为了深入了解ConnectionObserver与channelOperation在服务器端的协同工作，我们首先通过回顾PooledConnectionProvider的配置机制，了解到在服务器端配置ConnectionObserver的途径。具体来说，利用reactor.netty./post/
代码保护软件.NET Reactor 是什么
.NET Reactor是一个强大的代码保护和软件许可系统，适用于.NET Framework编写的软件，支持生成.NET程序集的所有语言。它的主要特点是防止知识产权盗窃，因为编译为Microsoft.NET框架的程序不会直接作为机器代码执行，而是被翻译成称为通用中间语言指令（CIL）的东西。CIL在程序运行时由.NET框架解释，而不是直接执行。
传统保护解决方案是混淆，但. NET Reactor提供更高级别的保护。混淆使源代码更难被理解，通过用无意义的名称替换类、方法、属性和变量的名称，但它对方法中的源代码没有作用。. NET Reactor不仅可以执行混淆，还能将知识产权包裹在更多的保护层中，拒绝访问源代码，即使是对您的辛勤工作决心窃取的个人或团体。
. NET Reactor通过多种方法防止反编译，包括生成不能直接理解为CIL的文件，在潜在黑客和您的.NET程序集之间构建了一个本机代码墙。这些方法包括行业领先的NecroBit技术，使重构源代码的难度大大增加。除了保护知识产权，. NET Reactor还提供强大的选项，通过使用各种试用版和完整版锁强制执行许可条款，保护收入流。
保护机制非常简单，只需要下载并安装.NET Reactor，在几分钟内生成第一个真正受保护的.NET程序集，无需对源代码进行任何更改。它提供简单可靠的方法来保护和管理您的软件。
