楼主辛苦了

又学习了一波

学习一下，感谢楼主分享的资料

引用：sunnyhui2010 发表于 2017-07-13 22:05
此方案中接入层和逻辑层是通过什么解耦的？mq还是rpc？

接入层和逻辑层是RPC框架。逻辑层内部通过Kafka解耦模块

引用：封宇_ynOMz 发表于 2017-11-23 14:31
接入层和逻辑层是RPC框架。逻辑层内部通过Kafka解耦模块

本文作者来了。。。

引用：JackJiang 发表于 2017-11-23 14:57
本文作者来了。。。

现在经常逛这个论坛，学到很多东西。感谢站长

引用：封宇_ynOMz 发表于 2017-11-23 15:35
现在经常逛这个论坛，学到很多东西。感谢站长

给你加V了：


你开发的IM是你们瓜子二手车公司内部用的吗？有好的心得记得大家一起分享

引用：JackJiang 发表于 2017-11-23 16:07
给你加V了：

内部用，线上用户和客服、销售沟通也用

请问拉离线消息时，如果离线期间消息特别多是怎么处理的？

引用：novo 发表于 2018-02-28 20:48
请问拉离线消息时，如果离线期间消息特别多是怎么处理的？

这两篇文章里讨论了你提到的问题，你参考一下：
《移动端IM登录时拉取数据如何作到省流量？》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》

重复发生了，这条已经去掉

"ISO采用APNS，Android真后台保活"应该修改为"iOS采用APNS，Android真后台保活"

引用：TheBloodElf 发表于 2018-03-28 15:01
"ISO采用APNS，Android真后台保活"应该修改为"iOS采用APNS，Android真后台保活"

已改，感谢纠错！

学习了

和我们的架构有点像，虽然并不完美，也无法支持太高的并发，但是能看出来确实是干活。我们的群聊是读扩散，写扩散用在实时的群聊中，我觉得在群成员数和群数比较多的时候，势必是灾难。

引用：researchboy 发表于 2018-06-05 20:23
和我们的架构有点像，虽然并不完美，也无法支持太高的并发，但是能看出来确实是干活。我们的群聊是读扩散， ...

你回想一下QQ群是怎么慢慢从50人、200人、500人、1000人群这些做起来的了。
群聊其实并不是个很简单的问题，只是大厂经过N个版本迭代后，大家都理所当然的认为群聊理应是标配或白菜技术才对。
所以，一方面是技术优化到极致，另一方面也是软硬件基础设施堆起来的。这个事对谁来说都不容易，大厂也一样

引用：JackJiang 发表于 2018-06-05 21:24
你回想一下QQ群是怎么慢慢从50人、200人、500人、1000人群这些做起来的了。
群聊其实并不是个很简单的问 ...

是的 非常有道理
我们刚刚做群聊，感觉里面的水很深，但是其他部门的同事，觉得群聊是微信好多年前就有的功能，应该是很基础的很简单的白菜技术，
看了本站的另一篇文章，单聊和小群写扩散，大群读扩散，是比较合理的方案

引用：researchboy 发表于 2018-06-06 16:22
是的 非常有道理
我们刚刚做群聊，感觉里面的水很深，但是产品和其他部门的同事，觉得群聊是微信好多年 ...

是的，微信和qq的迭代过程是他们的事，他们已经走过的路踩过的坑，不代表你们可以跳过，并不会把迭代成果给你用啊，哈哈

目前这样的方案算是比较合理

引用：JackJiang 发表于 2017-07-14 11:01
要实时性好肯定是RPC，但主要看你的应用场景是看重性能还是实时性

接入层与逻辑层，怎么通过RPC框架解耦的，实在想不通了。哪个算是RPC里的consumer，哪个是provider

引用：hello1234 发表于 2018-07-03 17:14
接入层与逻辑层，怎么通过RPC框架解耦的，实在想不通了。哪个算是RPC里的consumer，哪个是provider

这其实两方都有可能是对方的生产者或消费者。正确地理解是：接入层是专门用来管理客户端长连接的，客户端发出或收到的消息都是通过这个接入层来完成的，这也是socket长连接程序的特性。