高性能的IM服务器端的数据持久化问题该怎么设计和处理

在IM开发里，服务器端数据持久化一般是怎么实现的？
论坛里的技术贴几乎没有讲这个方面的，由于需要使用很多服务器，担心会有竞争条件的产生以及并发情况下出现问题，因此想要在数据库服务器上运行一个代理程序，接受其他服务器发来的增删改查请求，并将结果返回。消息服务器和数据库代理采用tcp长连接。
这里就有个问题，消息服务器和数据库代理的交互采用同步还是异步，同步必然会导致性能下降，异步的话消息服务器收到了返回数据怎么知道是要干嘛的呢？
如果加上redis进行缓存的话又该怎么处理
以上是我个人想法，水平太差 忘各位大神给一个比较方便的解决方案。

引用：小白白白 发表于 2016-10-26 22:01
现在是想按teamtalk的思路来自己实现一个，但是我是用go写，c++用的不多没有研究过tt的代码，就按着它的架 ...

Go好在哪，感觉Go出现的频率越来越高了，难道又得去学Go？靠啊

现在是想按teamtalk的思路来自己实现一个，但是我是用go写，c++用的不多没有研究过tt的代码，就按着它的架构来一点点学习和实现

引用：只是路过 发表于 2016-10-26 21:19
楼主几年工作经验了？之前主要干的哪一块？考虑的挺细的

刚入门。。还没什么经验，只是喜欢 就研究了一些，感觉现在思路受teamtalk影响比较大

引用：PonyZhao 发表于 2016-10-26 21:18
你们几个人做IM？不会是你一个人吧，关键你还没经验，这有点悬啊

我是自己感兴趣，然后自己写，不是公司，我还是学生。。没有工作，之前一直做web和ios 做腻了想转一下

引用：JackJiang 发表于 2016-10-26 20:10
异步是必然的，否则再牛逼的服务器单机也很容易出现瓶颈，去看看高性能网络编程的C10K编程：http://www.52i ...

在论坛的帖子里有看到您讲的这些知识，用http访问一些非实时信息这些内容我也有一定的了解，可能我问问题说的不太清楚。。可能有一些情况下需要和数据库交互，比如存储聊天记录，我是想问在这样的情况下是不是也只需要一个tcp包发给dbproxy甩给它就完了。。因为我刚入门了解的不是很多。。想知道主流的情况一般都是怎么处理持久化的

引用：JackJiang 发表于 2016-10-26 20:10
异步是必然的，否则再牛逼的服务器单机也很容易出现瓶颈，去看看高性能网络编程的C10K编程：http://www.52i ...

又学到东西了，感谢群主。

楼主几年工作经验了？之前主要干的哪一块？考虑的挺细的

你们几个人做IM？不会是你一个人吧，关键你还没经验，这有点悬啊

异步是必然的，否则再牛逼的服务器单机也很容易出现瓶颈，去看看高性能网络编程的C10K编程：http://www.52im.net/thread-566-1-1.html

其实，真正生产下的IM服务端，不会像你考虑的一样什么都混在一起，想到哪写到哪，这样必然一片混乱，而且像IM这种通信密集型的应用，性能指标都是按每秒几万的处理效率来衡量，跟普通的HTTP应用有很大区别。

所以，IM的服务端大家都会按功能、按业务进行拆分，比如：将好友信息的读取、存储、修改等不需要即时通信的业务拆分到独立的HTTP服务中去完成，而像文字通信这些基础的IM功能、以及加好友请求、上下线通知这种必须要实时通信的，才会放到即时通信这一边。

如果你们有有IM开发经验的程序员，他们可以很容易地想到，经过上面业务的拆分，几乎很少需要IM即时通信模块直接去跟持久化数据库打交道，最多存储一下聊天记录、或者实时加好友请求、上下线通知（因为上下线通知可能需要查询发起人的好友列表，而这为了提高性能，它又完全可以从高性能的redis缓存中读取，所以性能问题也不存在）等，而聊天记录这种数据完全可以通过MQ这种中间件来进行性能去峰处理，完全不存在性能瓶颈，大不了MQ因为处理量太大，延迟个几秒才处理完（存储到历史记录DB中），这又不影响什么。

总的来说，一个完整的IM服务端，是按照即时通信服务和普通的数据服务（比如http调用等）进行拆分和整合，而不是什么都放到IM模块里，虽然方便，但性能问题是很难以处理的。IM服务这边既要保证高性能又要保证处理的效率（对用户来说体现的就是即时性），而且几乎找不到标准的东西来用都得自已整，所以这就是为什么说IM开发比较难的原因。而普通的数据服务像HTTP接口这些就用传统的互联网架构处理就行了，大把的方案。