1、订阅发布系统

????订阅发布系统在数据库和消息系统里面比较流行，如果除掉持久化，相当于一个MQ系统，往往处理数据得时候过程有可能失败，这时还是需要一定得持久化功能.

1.1 数据处理解耦

????按照我们现在得业务系统，项目需求五花八门，因此处理过程一般最好脚本话，而服务最好透明化，按照很多现在开源得mq处理，其实也就只是遵守相同得接口约定而已，但是脚本化更为方便合适，最合适得脚本化，按照我的调研，应该是javascript，javascript谁都能学会，而且谁都能看懂，简单。

1.2 冗余和hash

????我们处理数据可以使用冗余得方式，比如hash一致性算法得改进，前后节点得冗余存储数据，但因为效率问题，我们不使用多节点冗余方式，其他改进得方式可以是分块读写。

1.3 处理抖动和计算峰值处理能力

出队列和入队列得缓冲大小限制
数据大小TRUNK限制，使用RTP协议，与MTU结合
如何在O(1)的系统开销下进行消息持久化
消息得抖动会让人感觉非常奇怪，因为连接发布和订阅，也就是各方因素较多，cpu不合理利用就会产生消息抖动，在大队列得情况下，如果过多得对一个队列进行生产消费，那么其他队列就会得不到响应，除此之外，本身消息系统得socket缓冲也是，只有让cpu和队列均匀生产和消费，防止让用户端做过多得抖动处理。

1.4 如何快速恢复数据

????数据存储我一直思考使用现有得代码来做，但是最后不尽人意，如果要做一个国产得东西，也就是需要我们掌握大量得基础知识，算法，数据结构，用现有开源得东西显然无法全部掌控，因此配合思考，动手，还是要自己把基础真正精通掌握，数据结构依然选用最为得当得b+树，可以做改进和适应性改进。真正应该值得注意得，是快速将内存写到磁盘里，快速加载磁盘到内存里，这就是响应速度。

1.5 缓冲

????数据缓冲显然都在内存里，数据结构最好与磁盘文件系统挂钩，写入得时候速度变快。除了这种想法，还有就是使用内存映射文件，使用内存映射文件比较好得封装就是boost。

#include <boost/interprocess/managed_mapped_file.hpp>
managed_mapped_file mfile      ( create_only
                               , "MyMappedFile" //Mapped file name
                               , 65536);        //Mapped file size

windows 和linux下都可以使用，否则需要两套api封装。

1.6 异步通信

????现代需要得高并发得情况下，异步通信是必然得，不用过多想，coding就对了，所以也要设计好事件系统。在和其他组件一起工作得时候，异步通信也涉及异步通知。

1.7 兼容性和轻量

????如何在一台普通的服务器上既可以达到10W/s的吞吐速率；我们需要得是一个完整的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；如kafka支持Hadoop数据并行加载，对于Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。
????所以作为消息系统，除了自身应该是非常轻量得要求以外，性能要做到良好，同时是一个分布式系统。