1.连接管理
网络架构原来是使用是自己开发的网络框架Gecko,Gecko默认为每个网络连接分配64KB的内存，支持1000个网络连接，就需要大概64MB的内存。后来采用Netty重构了网络服务层。
在Netty4是采用 Reactor Pattern线程模型
- 所谓Reactor Pattern模型是IO multiplexing event loop,Reactor负责处理所有IO事件，同时dispatching各IO事件的handler。
- 在新的模型中,有一个Boss线程池和Woker线程池,boss线程池主要处理socket accept事件，worker线程主要处理socket读写事件
- Boss线程在处理完socket accept请求(实际也只有一个NioEventLoop在处理accept事件)后，向Worker线程池取出一个NioEventLoopIO线程(默认轮询策略)注册刚建立连接的Channel(socket连接),此Channel生命周期内的所有读写事件都由其注册的NioEventLoopIO线程负责。
2.存储管理
数据库存储
支持异步和同步的数据库消息记录创建和更新，时序图如下
文件存储
存储分为物理分区和逻辑分区，物理分区存储数据，逻辑分区存储各个消费者需要的消息的索引，文件以DirectByteBuffer方式打开，消息顺序存储和顺序消费，性能非常高。
接收和发送数据都采用 FileChannel Transfer的方式进行数据拷贝，减少内核态和用户态的转换，减少gc。
分布式文件的基本结构
3.分组管理
消息存储
到消息时先通过订阅关系知道这条消息有哪些订阅者需要订阅，然后把这条消息的索引对应的订阅分组的逻辑分区里面去，分区的选择采用随机策略。消息存入逻辑分区时需要把消息序列化为通讯层传输的格式，便于使用零拷贝特性。
消息拉取推送
- 系统启动时根据订阅关系获取所有订阅分组的信息和分组对应的分区的信息，然后顺序启动每个订阅分组对应分区的拉取消息的任务，比如订阅组A有5个分区，则会启动5个任务分别的去5个分区里面并行获取消息并投递，每次获取消息的数量支持批量。
- 每个任务获取消息时都需要获取任务锁，投递完消息后需要释放任务锁，保证获取消息
- 任务对每个分区是单线程访问的，避免消息重复投递。
- 任务启动时还需要向任务监控注册，保证由于线程池异常或者其他异常导致任务异常终止时能够自动恢复超时的任务，继续获取消息并投递。
- 订阅关系新增时自动监听并启动新的任务投递新订阅分组的消息，当订阅关系删除时自动停止对应的订阅分组的所有任务。
- 当某个订阅者的分区数增多时自动增加一个该分区的任务获取并投递消息，当分区数减少时需要把减少的分区的消息投递完后才停止该分区的任务并释放相应资源。