即时通讯体系M存储设计 之 读写放大的思考

读写放大

目前的架构按照将用户根据userID等范例进行分类存储，由于每个用户在每条信息上的状态都不一样（用户间信息特征具有唯一性）。所以在下发的过程需颠末userID -> sessionID -> deviceID的路线进行多次查询。如上文所说这是其中一个性能瓶颈，也就是所谓的读放大题目。
读放大

   Q：严谨地表明一下读放大题目界说
  A：读放大题目（Read Amplification）是指在数据库或存储体系中，为满足一个读请求而进行的现实读取操作量远远超过了原始请求所需的数据量。简朴来说，就是体系为了获取某一数据块，而不得不读取更多数据，从而导致读操作的开销增大。
  可以办理这个读放大题目吗？
写放大

可以，简朴粗暴的一种思路是将消息的状态联合消息自己一起存储。但是这种做法也就意味着每个用户都必要存储一份对自己可见的消息，由于每个用户可见的消息都是不一样的。
大概有人会问为什么不以消息的存储为中心，下发的时候再去查询呢？由于这么干的话就回到原点成为读放大了…
但是这个思路起首对内存的压力是巨大的。在写的时候（上行消息），消息必要颠末处理惩罚，这个处理惩罚可以是序列化，压缩等。而且每当消息的状态发生改变，都必要将消息相干信息取出，修改后重新写入。那么题目又来了，这种处理惩罚就形成了范例的写放大题目。
   Q：严谨地表明一下写放大题目界说
  A：写放大题目（Write Amplification）是指在数据库或存储体系中，为满足一个写请求而进行的现实写入操作量远远超过了原始请求所需的写入数据量。简朴来说，就是体系为了写入某一数据块，而不得不写入更多数据，从而导致写操作的开销增大。
  

---

将上述的特点总结一下就是：

• 读放大：
  
  
  
  • 存储本钱小（无冗余消息）
    
  • 存储服从高（无压缩等）
    
  • 存储一致性强（存储结构独立）
    
  • 写复杂度低，多次嵌套读。
    
  
  
• 写放大：
  
  
  
  • 存储本钱高（用户为单位存储消息列表）
    
  • 维护一致性本钱高（修改需先存再取，服从低）
    
  • 写复杂度高（压缩等操作），读复杂度低。
    
  
  

两种设计思路所对应的是两个极度。在IM中，我们可以根据不同会话的场景来设定不同的模式，联合两者的部分思考，局部使用。
对于绝大部分情境下（单聊 &小群聊）的IM，我们还是会接纳写放大的模式。主要是在IM架构中，将消息有关属性入库自己可以设计为一个异步的过程（联合MQ），所以写相干的指标对比之下不大重要。而且读的服从会更高。但是会牺牲一部分内存。（人不多的情况下，缺点不凸显）
但是对于大群聊 & 活跃群聊来说，由于成员的基数大。若接纳读放大模式，每一次的发送 / 下行消息都会引发大量并发读，并发写的请求。这其中虽然写这一过程自己是异步的，但是他还是消费了大量的服务器CPU资源，从而影响团体的性能。另一方面，让大群聊各成员都存储一份消息列表，自己就造成了不小的空间负担。因此牺牲维护一致性的本钱，使用读放大模式，在减轻写负载的同时，也保证了服务器的稳固运行。也节流了存储空间就是了。
这只是针对大部分的常规情况而言，具体情况根据IM具体的业务场景作分析。而且怎样界定 单群 & 小群聊 or 大群聊 & 活跃群聊 ，也必要在测试之后，根据服务器的性能来权衡。更可以通过每小时消息数与平均活跃时长等尺度。设置一个活跃&非活跃群聊状态切换的算法，更好服务各情景。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。