腾讯云通信聊天记录同步实战，与云通信巨头合作的点点滴滴，涉及技术选型、技术实现、同步方案设计，统统一线切身体会，躺坑在前，后来人有福啦！
云通信选型
比较了阿里旺信、网易云通信、容云通信、极光IM多款产品，一轮选型，直接锁定在阿里与腾讯云通信，这个主要是选择大品牌的出发点。第二轮锁定在腾讯云通信，这个的出发点在于，腾讯的微信可能会屏蔽阿里产品，就像淘宝之类的产品，在微信都是可能屏蔽掉的。再一个就是，旺信的文档显示，这个产品提供的文档很少很有限。相对之下，腾讯云通信的资料还是更齐全。
聊天记录同步技术方案
有两种方案可以将历史聊天记录保存下来，一是对接腾讯云通信的聊天回调通知，实时接收聊天信息。另一个方案是周期性拉取腾讯云通信的聊天记录。我们选择了方案二。因为方案一是实时的，如果聊天过于火爆，可能会我方的服务器带来压力。方案二，则不会出现压力问题，我们只需要慢慢的去拉取，有点错峰处理的意思。
历史聊天记录同步的技术实现
技术实现上，采用java开发语言堆出来一个后台服务程序，这个后台程序运用到了redis,myql，cron,springframework,ibatis、分布式锁，在遵循代码中的方法不能有超过一屏，严格区分bll,service,agent等代码规范要求下，实现了一版历史聊天记录同步程序。
1.分布式锁的运用
为了防止多个服务器实时并发跑，造成重复拉取，我们要运用分布式锁。最开始的时候，当同事们聊到分布式锁，我感觉好高大上啊。当我打开工历史代码，仔细看看目前的三种实现方式，就感觉，嗯嗯。1.是使用mamcache，2.是使用redis，3是使用zookeeper。经过咨询多个前辈。这个项目，就选redis了，因为我们需要使用redis做些缓存，正好又拿来实现分布式锁。这个是基于redis.setnx，原子性操作，如果key存在，则会设置失败，利用这个特性，实现了一个分布式锁。
2.cron+springframework
作业的调度，采用了springframework的任务调度功能（schedule），配置一个cron，感觉还是很方便。想想不用自己去创建线程，不用自己去启动线程，只需要安心的写业务代码，有点小小的开心。
3.ibatis
嗯嗯，ibatis几乎融合在所有的项目里，用来操作数据库，还是很贴心的。就不再八卦了，
4.严格的代码规范
一个方法的长度不能超过一屏。嗯嗯，怪不得有同事把屏幕坚起来写代码。我的字体设置的比较大，又是横屏显示，这个有点点挑战。我先把主体逻辑写完，以业务实现为目标，完成业务代码的实现，这个阶段，我并不太考虑代码分层是否合理，一个方法的代码是否在一屏之内。等业务逻辑实现好了，我再进行代码重构，要拆的拆，要分的分，这种方式还是很不错。一边写，一边可以思考怎么拆更合理，等业务实现完了，基本上对代码重构有了一个完整的重构思路。当然，找一个有经验的同事一起重构是最重要的经验啦。
5.我们的代码逻辑
一个分布式锁，一个按天调度逻辑，一个按小时调试循环，再到聊天文件解析，将图片链接替换成长期存储连接。
小结
今天主要介绍了一下我们与云通信巨头对接历史聊天记录的实战经验，你应该能知晓我们为什么在众多云通信厂商中选择腾讯云！并了解我们历史聊天记录的同步方案以及所使用到的技术。好了，今天的分享就到这里了，一期文字，码了好久！期待下一期！
技术岛公众号