服务器入门之一 ---- 以数据库为中心

此是多年来第一次认真写点东西， 是为分享这几年积累的些许经验，并且后面再招新人，

都只让他们来看这些文章就够了，不再一点一滴去教。

开始这一系列的书写，主要受这个文章影响，唐巧的《作为码农，我们为什么要写作》，

没开始看，光看了标题，我就想到，我是该写写东西了。

曾经，我入了一个误区，开发的时候，如果有个功能上是比较逻辑独立的需求，我就会想要

用已经成熟了的服务器模板写一个新的功能服务器来支持。结果，导致有大量的功能服务器出现，

五花八门。这是一个严重的问题，管理起来麻烦，维护起来更麻烦，很伤脑筋。

切入正题，以数据库为中心，数据库这里不单指关系型数据库，还包括NoSQL中的键值数据库，

文档型数据库。这么看问题，我们服务器最终是输入输出，还有保存中间数据。而这个数据恰好是

整个过程的中心，一切其实都是围绕数据来的，不管这数据在哪里，是永久存起来，还是临时cache

了，或者只存在于服务器与服务器之间的通讯之中。

举个例子，我们的游戏平台要实现一套im系统，支持聊天，以及相关游戏功能的交互，我们

本来没什么这类经验的，所以一开始的时候比较抓急，当然也按照各个功能点的实现，设计出了整个

系统，但几乎都是要手写各种服务器来支持，比如要保存跟广播用户的状态变化，就写了状态服务器，

要缓存用户的基本信息，避免对用户数据库造成太大的压力，就写了用户信息服务器，要转发用户之间

的聊天消息，就写了聊天服务器，要管理用户之间的好友关系，就写了好友服务器...

这时候已经看得人有些小崩溃了。是的，我们就这样实现出来了，当然，也正常的跑着，不过时不

时出点故障，因为系统复杂了，一个小地方出问题都会影响到全局。

没写过烂东西，其实很难体会一个好的东西要是什么样子的。

就上面讲的，直接说下如何优化，这时候就得以数据库为中心了。

状态服务器： 得用redis这种内存数据库来改造，1.状态的存储，直接写入redis，2.状态的广播，直接使用redis的订阅发布其实就够了，把一个个用户当成一个频道，它的好友所在的连接服务器都可以订阅它的好友的频道。

用户信息服务器：也用redis或memcache就够了，在访问用户数据库前先去redis取一下，取不到再从用户db取，取了set回redis。

聊天服务器：可以不存在的，连接服务器之间直接

好友服务器：可以不存在的，如何处理加好友请求？连接服务器（其实这里是一个小小的逻辑服务器，会有多个来承载所有的用户连接）直接将请求写入数据库返回一个请求id，再从redis取出目标用户所在的服务器，直接向该服务器发起一个通知，目标服务器收到通知，如果被加的人在此服务器上，则从db取出这条请求来处理，否则就等用户登陆的时候取出所有的离线请求来处理。 如果处理同意加好友请求？也是连接服务器直接来。