- 论坛徽章:
- 0
|
1. 整体框架
整个服务器组由三个部分组成，客户端（Clientsvr），代理服务器(proxysvr)，数据库服务器(sqlsvr)，客户端通过代理服务器对数据库服务器进行访问，不能跨层访问。
2. Sqlsvr
这层的服务器跑mysql和sqlsvr，sqlsvr是我们自己写的一个应用程序，主要是访问本地数据库，提供统一的访问接口，监控，也是后面的扩服等需要。整个层的数据库都只能通过sqlsvr进行访问。下面将对该层的服务器称为sqlsvr
2.1. 这层的服务器分成若干组，每组由多个sqlsvr组成，1个主，多个从，用来做读写分离。如上图8个sqlsvr，分成4组，2个一组，一主一从
2.2. 数据库中的表分散在各个组中。每个表中的主key做为存储在哪个sqlsvr上的依据。比如user表中userid是主key，将key除以4，余1的存储在第一组，余2的存储在第二组。当然实际中的计算方法稍微复杂一点。
3. Proxysvr
Proxysvr也是我们自己写的应用程序，功能和mysql proxy差不多，可能看到这里大家会有疑问为什么不用mysql proxy，这个后面再解释。
3.1. Proxy主要进行负载均衡，解析sql语句，根据sqlsvr的负载，决定分配到哪组的哪个sqlsvr。
3.2. 缓存数据。每次查询的时候先查找本地，如果没有在从sqlsvr上取。甚至有的写操作都在本地进行。
3.3. 处理需要操作整个表的sql语句，比如查询最大的数。
4. 心跳服务器组
心跳服务器以机房为单位，一个机房一组，会定时查询该机房的每个服务器的运行情况。Proxysvr会也有心跳服务器的功能，作为心跳服务器的备份。
5. 操作类型
因为proxysvr有缓存作用，所以一般一个proxysvr会对映几个组，访问这组的服务器都会通过特定的proxysvr进行。但是并不是所有的sql语句都遵守这个规定，而且proxysvr会有宕机的时候，所以需要将sql语句分成几个类型，不同的类型有不同的操作策略。
5.1. 涉及事务的操作，后面会详细解释。
5.2. 重要数据。读操作必须从sqlsvr中读取，写操作必须通过sqlsvr写入mysql后才从proxysvr返回给client。
5.3. 一般数据。写操作会写入proxysvr中，进过一段时间将脏数据刷入sqlsvr。读操作必须通过指定的proxysvr读取。
5.4. 容忍误差的数据。写操作如同3，读操作根据打分策略选择指定的proxysvr或则其他的proxysvr读取。
6. 读写分离
通过proxysvr解析sql语句，对不同的sqlsvr进行读写。
7. 数据库的访问方法
每个表会有个主key，通过算法转化成32位的数字X，然后对X取模，余数为几就在第几组服务器进行访问。
8. sqlsvr扩服
如果是单纯的读压力过大，会增加从sqlsvr，如果整组压力过大，会增加一组服务器。然后更新proxysvr的分流的算法。因为我们是在线扩服的，实际情况会复杂点。比如，我们发现1组的服务器的压力超过某个临界值，我们会添加一些从sqlsvr在这一组，等数据基本同步后，控制台服务器会通知全部的proxysvr，proxysvr会进入扩服阶段。此时proxysvr会拒绝4.1操作，阻塞涉及到扩服的sqlsvr的写操作，直到扩服务完成。等数据全部同步完毕后，然后将之前添加在1组的从服务器变成新的服务器组假如是2组，2组依然是1主多从的结构，扩服完成。经过一段时间的稳定后，删除1组上的老数据，删除2组上本来是第一组的程序。此外Proxysvr还会更新分流的算法。比如有a,b,c,d组服务器，以前的key是模4，再发现a组压力大后，添加e组，现在扩服后key就会摸8，余0在a组，余1在e组，余2，余3都在b组。
9. proxysvr数目变化
因为4.3操作会到指定的proxysvr，client会通过心跳服务器来计算4.3操作应该在哪个proxysvr 上进行，当数目变化后，client会更新。
10. 宕机
Sqlsvr宕机，如果是从，proxysvr会更新算法。如果是主，那么会选择1个从sqlsvr变成主sqlsvr。
Proxysvr宕机，在一定时段内，4.3的操作会阻塞，直到proxysvr恢复。其他操作无影响。超过指定时间段，proxysvr的数目会更新，如同9。
11. 事务
我们做的事务不能算事务，只是为完整性做的功能。单个sqlsvr的事务没有变化，当涉及多个sqlsvr的事务的时候，会在proxysvr上进行处理
11.1． 向涉及的sqlsvr提交开始事务，拉取数据。
11.2． 修改数据，存储本地log。
11.3． 提交修改数据，提交事务。等待反馈。
11.4． 如果因为网络宕机等原因，会在下次sqlsvr连接正常时提交。如果多次依然会未能解决，报警，人工介入。
这部分一直没有找的好的解决方案，如果大家有好的方法，希望能指点下。还好需要人工介入的时候概率非常低，因为这种情况一般是硬盘原因，而且还有数台备份，一起坏的概率太低了。
12. Clientsvr
Clientsvr主要是对外提供数据库的访问，让用户感觉只有1个数据库，屏蔽后面的细节。
Clientsvr目前做了2种，一种是封装好的源码，数据服务器编程的时候就一起编译。一种是当成服务器跑，业务服务器通过协议进行连接。其实整个程序的框架是真实的用户连接到前面的连接服务器，逻辑由各个业务服务器来处理，业务服务器将复杂的数据操作交给数据服务器，数据服务器会通过clientsvr对数据库进行访问。业务服务器也可以通过clientsvr来访问数据库。
13. 其他
轮子这个问题就不多说了，这个设计很多上也是公司业务所决定的。当初设计的时候本来是想完全不用考虑业务的，做一个比较通用的分布式数据库。但是后来不得不在通用性和效率之间折中，所以结合业务砍掉了些功能。比如老数据和新数据的热点问题，以前的方案会区分处理的，比如会有老数据库和新数据库，有增量查询，新老数据融合这些东西，但是开发成本大，收益底，对公司业务没有帮助，就被砍了。虽然大家觉得比较酷。以后要是有这方面的需求，只能通过业务上来做处理或者通过合理的主key分配来解决这些问题。
这个数据库有很多覆盖分布式数据库的特点，读写分离，分表，没有单点，高并发，在线扩容，局部数据之间没有干扰等。
但是数据库不支持外联，不支持jion这些跨表的操作，这些操作或者对数据完整性的保证全部通过业务逻辑来做。
数据库回档很繁琐，需要人工介入，哪些大侠有这边面的经验，请赐教。
|
|
免费注册
楼主: send_linux
发表于 2012-09-01 12:36
发表于 2012-09-04 22:32
