本文将会给大家介绍如何开发一个简单的即时通讯系统(IM)。
为什么不简单
我们的站点加一个即时通讯(IM)的功能，那么我们怎么做？
在回家的路上，问了同是实习生（网络方向）的舍友这样一个问题，他回答：“很简单，只需要在服务端保存一个list，收到一个人的message后，我转发给list中指定的另一个人就好啦”
接着，我们讨论了一晚上下面的几个问题
1.对方不在线怎么办？
2.内存里保存list的话，人多了怎么办？
3.怎么查看历史记录？怎么多端同步数据？
4.为什么微信用户只能建立有限个群，并且群聊功能很晚才开放？为什么微信好友数是有上线的？
5.怎么保证消息有序、不丢失数据？
6.如何保证消息的时效性?
7.如何承担高并发流量？
后讨论的结果是：开发一个稳定高效的IM产品是相对困难的，上面这些难题，QQ、微信等产品都遇到过。IM产品一旦量达到一定程度，性能、稳定性、可用性等的挑战会越来越大，开发维护都十分困难，需要不断的打磨锤炼，才能保证是一个可靠稳定的IM产品。
为什么简单
同样是一个IM的小白，在看到tableStore产品的timeline模型后，只花了一个下午的时间，就理解了IM和做出一个可使用的demo。
Timeline模型是TableStore团队针对消息数据场景所新创的一个数据模型，它的特色在于能够满足消息数据场景对消息保序、海量消息存储、实时同步的特殊需求。目前Timeline模型主要能够解决以下场景的需求：
1.IM:如钉钉、微信
2.Feed流：如微博、朋友圈
3.IOT消息下推：如天猫精灵
4.无限Topic的队列
具体的文章可以参考：
•TableStoreTimeline：轻松构建千万级IM和Feed流系统
•TableStore数据模型-WideColumn和Timeline
介绍
我们来完成这样的一个即时通讯产品的demo。正因为是一个demo，我们关注核心功能，在设计和其他功能上都会从简，方便大家理解和阅读。
1.设计功能
•一对一私聊
•群聊
2.表结构
目前版本的timeline只解决消息存储和同步问题，其他元数据相关的表还是需要我们自己来完成的。下面所有的表都使用tableStore这款NoSQL分布式数据库进行存储，存储量和并发不用担心。