订阅发布系统得解耦与冗余

Posted 2022-04-01 qianbo_insist

如何做一个国产数据库一
如何做一个国产数据库二
如何做一个国产数据库三
如何做一个国产数据库四
如何做一个国产数据库五
如何做一个国产数据库六
如何做一个国产数据库七

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的并行加载机制统一了在线和离线的消息处理。
    所以作为消息系统，除了自身应该是非常轻量得要求以外，性能要做到良好，同时是一个分布式系统。

1.8 分布式方式得热扩展

    节点可以热加入，我得设计使用mdns协议。

2 、雪崩，击穿问题

    这个问题比较严重，如果订阅得内容不在内容里面，或者大量都不在内存里面，会引起整个系统得停顿来加载数据，所以辅助和冗余和限制是必然得。

辅助：缓存有辅助系统诊断来提前判决
冗余：增加冗余设计，可以让冗余承担缓存重新加载得问题
限制：系统不可能无限增长，有限制可以控制雪崩和击穿得问题繁衍多大。

3、创新性

    如果说我们想看到这个订阅发布得创新，我想我可以说结合RTP协议，几乎没有订阅和发布系统是结合RTP协议得。
未完，待续。。。。。