本质是 一次rpc变为两次rpc，以此来解决满足不同的业务场景问题,如

• cache 流量产生者对消化者的 服务压力问题，如异步发短信，现有才10个qps的短信网关要支持300qps的producer，若是同步短信则必会卡住producer,那么可以把短信数据存放到queue中，在满足业务的需求下，稍后发送;
  
• 广播 消息通知, 单点服通知多服务内存中的热数据(配置，业务数据)更新
  
  

其中的技术关键点在几个:

消息的传递 #

• 消息的顺序性,解决点在于 seq序列号的应用
  
• 重传,是否保证消息到达或者消息传输的可靠性（一定到达，或者错误一定可以定制处理）; 解决点在于 应用seq和ack,即序列号和确认处理的使用, TCP协议的处理是很典型的参考（对于后端开发TCP最基本不过了)
  
  

数据存储 #

• 最大化的不让数据丢失，解决点,简单的讲就是在set and get上面的优化
  
  • 如 数据从RAM持久到disk的策略如当数据大于一定体积（可配置)后将数据刷盘,flush by data size; 或者定时刷盘flush by time ticker;或者两者结合使用; 而flush to disk的过程中，kafka只对数据append的处理大大加快了数据在disk上的持久化过程
    
  • 获取数据时若是在RAM中，则考虑优化查找算法，减缓CPU; 若是在disk中，则考虑zero copy来减少user space and kernel spacke 的上下文传递损耗,如kakfa
    
• 存储体积上的优化,解决点在于数据encode and decode，比如protocol buffer
  
  • 体积小 protocol buffer（采用TLV:tag length value的位控制技术来最小化数据体积;
    
  • 快 相比于text-based协议如json,xml等,binary-based的protocol buffer位操作得益于数据小，减少了数据在解析时的运算和读取写，效率一般比text-based要高,
    
    • Both text-based and binary-based serializers can be fast and efficient (or slow and horrible)… just: binary serializers have the scales tipped in their advantage. This means that a “good” binary serializer will usually be faster than a “good” text-based serializer.)
      
      

分布式服务的状态管理 #

• 一说到分布式，就联系到了CAP,RAFT,PAXOS理论，不过简单的描述，这里的解决点在于 服务发现的应用
  
  

看了NSQ和kafka的处理,记录一下