IM即时通讯-1.0版成果展示与后续扩展（七）

V1.0成果展示

聊天页面

添加朋友、搜索好友、好友申请

申请列表、好友列表、未读消息气泡显示

IM即时通讯常见问题及后续扩展

已经从0到1实现了单聊，但也仅仅是实现了而已，很多容错机制、事务机制都没实现，比如：

1. 如何保证消息送达？

这里送达是指消息能到达服务端，如果这个消息连服务端都没到达，又谈何送达对方。这里会涉及到消息应答机制。针对本次0到1的实践，其实这个应答已经实现了，消息发送到服务端后，服务端会生成消息id，并封装到消息体中返回给客户端，这个返回的过程，其实就是一个应答的过程。

如果没有收到这个应答，或者说指定时间内没有收到应答，那就可以认为，消息发送失败，重新发送消息（消息重传机制）。

2. 如何避免消息重复？

没有收到应答，或许不是消息没到达服务端，而是服务端返回应答的这个环节出错了，如果这时候重新发送一条消息，对方可能会收到两条一样的消息。消息是先进入客户端的会话信箱，然后才从会话信箱中载出的，如果会话信箱中，msg_id唯一，也就是重复的msg_id进不来，那就可以解决了消息重复的问题。（在本次0到1的实践中，消息id是在消息到达服务端后才生成并封装到消息体的，所以相同的消息也不会存在msg_id一样的情况，不能避免消息重复，咋这么优秀呢，刚实现1.0就已经架好2.0了，~_~）。

3. 如何知道消息对方已读？

六重应答机制，确认对方已读消息：

 发送消息及应答：消息发出后，只要指定时间内发送方没有收send_msg_ack，将触发超时重传，直到收到send_msg_ack（确认消息送达），或设置一个阈值，发送次数达到阈值则不再发送。

已读消息及应答：对方收到消息后，会发出回应消息，如果指定时间内对方没有收到reply_msg_ack，则会触发超时重传；己方收到reply_msg，则确认对方已读消息。

4. 六重应答机制+超时重传机制，就能保证对方能收到消息了吗？

只要消息发送方没有收到对方收到消息的应答（reply_msg），则触发重传，直到收到对方收到消息；问题又来了，为了一条消息必达，触发100次（或更多次）重传，值得吗？显然是不值得，也不合理的。

又回到设计的最终理念：权衡。

设计一个重传阈值，比如是3，如果重传3次就能使消息必达率达到99.9%，刚好又能满足业务，那么这个阈值就可称为最佳实践阈值；如果消息必达率要达到99.99%，才能满足业务呢，那只能不断调试阈值，直至最佳。

最后

IM即时通讯从0到1的实践就告一段落了，有了这一段基础，无论是阅读开源的IM框架，还是将IM落实到自己的项目中，都能够对整体框架有一个全面的把控。

项目代码已放码云，down的同时别忘了来个star

IM即时通讯从0到1的实践，相关文章：

IM即时通讯-从0到1的实践（一）

IM即时通讯-项目框架搭建（二）

IM即时通讯-用户注册登录，及gin+JWT鉴权（三）

IM即时通讯-核心结构体设计（四）

IM即时通讯-消息id（五）

IM即时通讯-会话列表和会话信箱（六）

IM即时通讯-1.0版成果展示与后续扩展（七）<本文>