生活在别处: 四月 2010

2010年4月28日星期三

2010年4月21日星期三

Storage engine	MySQL version	Transactions	Lock granularity	Key applications	Counter indications
MyISAM	All	No	Table with concurrent inserts	SELECT, INSERT, bulk loading	Mixed read/write workload
MyISAM Merge	All	No	Table with concurrent inserts	Segmented archiving, data warehousing	Many global lookups
Memory(HEAP)	All	No	Table	Intermediate calculations, static lookup data	Large database, persistent storage
InnoDB	All	Yes	Row-level with MVCC	Transactional processing	None
Falcon	6.0	Yes	Row-level with MVCC	Transactional processing	None
Archive	4.1	Yes	Row-level with MVCC	Logging, aggregate analysis	Random access needs, updates, deletes
CSV	4.1	No	Table	Logging, bulk loading of external data	Random access needs, indexing
Blackhole	4.1	Yes	Row-level with MVCC	Logged or replicated archiving	Any but the intended use
Federated	5.0	Yes	N/A	Distributed data sources	Any but the intended use
NDB Cluster	5.0	Yes	Row-level	High availability	Most typical uses
PBXT	5.0	Yes	Row-level with MVCC	Transactional processing, logging	Need for clustered indexes
solidDB	5.0	Yes	Row-level with MVCC	Transactional processing	None
Maria(planned)	6.x	Yes	Row-level with MVCC	MyISAM replacement	None

2010年4月19日星期一

网站压力测试工具webbench

FROM: 找到一款不错的网站压力测试工具webbench

webbench是 *nix 系统下一网站负载能力测试工具，它最多可以模拟 3 万个并发连接。

安装

[bash]
[root@localhost tmp]# wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz
[root@localhost tmp]# tar xvzf webbench-1.5.tar.gz
[root@localhost tmp]# cd webbench-1.5
[root@localhost webbench-1.5]# make
[root@localhost webbench-1.5]# make install
[/bash]
通过webbench --help可获得各选项：

-f|--force 不等待请求返回。

-r|--reload 发送重新载入请求： Pragma: no-cache。

-t|--time 测试时间，单位；s，默认 30。

-p|--proxy server:port 使用 proxy 发送请求。

-c|--clients N 一次发送的请求数, 默认 1。

-9|--http09 使用 HTTP/0.9 协议发送请求。

-1|--http10 使用 HTTP/1.0 协议发送请求。

-2|--http11 使用 HTTP/1.1 协议发送请求。

--get 使用 GET 方式发送请求。

使用

[bash]
[root@localhost webbench-1.5]# webbench -c 500 -t 30 http://172.10.7.228/test/hs.php
[/bash]
测试结果：


Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://172.10.7.228/test/hs.php
500 clients, running 30 sec.

Speed=452878 pages/min, 174517 bytes/sec.
Requests: 10857 susceed, 215582 failed.

从请求结果中可看出，该服务器 500 个并发承受不住。

2010年4月17日星期六

JavaScript 全半角转换

规律：半角空格的 charCode 为 32, 全角空格为 12288. 其他半角字符 ( 33 – 126 ) 与全角 ( 65281 – 65374 ) 的对应关系是：均相差 65248.

找好规律，代码就好写了：
[js]
var hash = {'32' : '\u3000'};
// 半角转全角
function sbc2dbc(str) {
var ret = [], i = 0, len = str.length, code, chr;
for (; i< len; ++i) {
code = str.charCodeAt(i);
chr = hash[code];
if (!chr && code > 31 && code< 127) {
chr = hash[code] = String.fromCharCode(code + 65248);
}
ret[i] = chr ? chr : str.charAt(i);
}
return ret.join('');
}
[/js]

同理：
[js]
var hash = {'12288' : ' '};
// 全角转半角
function dbc2sbc(str) {
var ret = [], i = 0, len = str.length, code, chr;
for (; i< len; ++i) {
code = str.charCodeAt(i);
chr = hash[code];
if (!chr && code > 65280 && code< 65375) {
chr = hash[code] = String.fromCharCode(code - 65248);
}
ret[i] = chr ? chr : str.charAt(i);
}
return ret.join('');
}
[/js]
上面的代码会将 33 - 126 中间的符号也转换。很多时候，这并不是我们需要的（比如将 @ 转换为＠）。下面的代码侵入性更小：
[js]
var hash = {};
// 半角转全角。仅转换 [0-9a-zA-Z]
function sbc2dbc_w(str) {
var ret = [], i = 0, len = str.length, code, chr;
for (; i< len; ++i) {
code = str.charCodeAt(i);
chr = hash[code];
if (!chr &&
(47< code && code< 58 ||
64< code && code< 91 ||
96< code && code< 123)) {
chr = hash[code] = String.fromCharCode(code + 65248);
}
ret[i] = chr ? chr : str.charAt(i);
}
return ret.join('');
}
[/js]

2010年4月16日星期五

Apr 16th, 2010

努力让自己沉浸于专业的文章或是自己感兴趣的书籍、电影、音乐中，可脑子里总还是呈现一大段一大段的空白，灵魂好像总是神游于身体之外。

计划了很多很多的事情，但没坚持几天，因为这样那样的原因搁置以至于之后无限期的计划延长。是多想振作精神做一个众人眼中开朗的、乐观的、阳光的女子，哪怕是以前的假象都行。而事实呢，事实是怎样了？呵，我连假象都无意去维持了。

QQ上，大学同学同我聊起以前大学时的一些事情，并问我是否有出去游玩感受下春天的生机？呵，才发现自己从未曾想过这个。在仅能得到的那些属于我自己的时间里，我只愿意游荡在人潮汹涌的街头以遇见自己熟悉的身影，或是躲在自己小小的世界看书听歌不闻窗外的阳光灿烂，春意傲然。

曾经的挚友，恍然间，好像都已远去。曾以为，不管时光怎么流逝，地点怎么变迁，藏于我们心怀的那份关怀友爱温暖分享是永远都不会逝去的，但怎么可能了？终究那份情怀被高估了吧。或许，只是因为，TA们都有了新的生活，新的挚友，还有陪伴TA们一生的挚爱的人，每一天迎接TA们的是各样的新鲜，哪还有那么多时间和心情来应付旧时老友，又或许只是因为我身体在此刻，心却停留在回忆中。

刘若英在介绍新专辑《在一起》时说：「新专辑里有不少“否定”的歌名，譬如老朋友阿信制作的《我不想念》、张亚东制作的《你不要送花给我》，这样的设置是为了表现自己的爱情观，越是说不想，其实就是在说心里越想说的渴望。给出否定的答案，其实是希望生命中能出现肯定的结果。」生活在钢筋水泥陪伴电脑的时间比其他都长的现在，好似早已迷茫忘却了自己，于是自欺欺人的说着那些否定。但是夜深人静梦醒时分，那些被深深埋藏于心底的梦想、渴望毫无阻挡的冒出来时，唯有潸然泪下。

“在一起”，这是多么多么浪漫的三个字，曾在哪里看到过说，「当你觉得“在一起”比“我爱你”更浪漫时，只是说明你不在年轻，至少你的心也已不再年轻。」呵，在90后都已流行说站在青春的尾巴上的年代，我们这些80后，该以何种面目自居，至少至少已不是青春了吧！

2010年4月14日星期三

NoSQL 数据库漫谈

2010年4月2日星期五

http_load

FROM: http_load的使用

http_load，以并行的形式向 WEB 服务器发起请求来测试网站的吞吐量。因为运行时只有一个进程，所以不会对客户端产生压力。而且通过配置后，它还可以对 HTTPS 进行测试.

安装

[bash]
[root@localhost tmp]# wget http://www.acme.com/software/http_load/http_load-12mar2006.tar.gz
[root@localhost tmp]# tar xvzf http_load-12mar2006.tar.gz
[root@localhost tmp]# cd http_load-12mar2006
[root@localhost http_load-12mar2006]# make
[/bash]

使用

1 测试网站是否能承受住预期的访问压力
[bash]
[root@localhost http_load-12mar2006]# ./http_load -parallel 500 -fetches 1000 urls
[/bash]
同时发起 500 个请求，随机访问 urls 中的网址列表，总共访问 1000 次。运行结果：


1000 fetches, 30 max parallel, 339000 bytes, in 2.16711 seconds
339 mean bytes/connection
461.443 fetches/sec, 156429 bytes/sec
msecs/connect: 2.50347 mean, 25.948 max, 0.089 min
msecs/first-response: 21.6581 mean, 25.948 max, 20.699 min
HTTP response codes:
  code 200 -- 1000

从上面的运行结果来看，目标网站能够承受每秒 461 次访问。

2 测试网站每秒所能承受的平均访问量
[bash]
[root@localhost http_load-12mar2006]# ./http_load -rate 5 -seconds 100 urls
[/bash]
在 100 秒内保持一定的频率(5) 随机访问 urls 中的网址列表。


499 fetches, 1 max parallel, 169161 bytes, in 100 seconds
339 mean bytes/connection
4.99 fetches/sec, 1691.61 bytes/sec
msecs/connect: 0.118295 mean, 1.058 max, 0.077 min
msecs/first-response: 2.25691 mean, 4.619 max, 1.958 min
HTTP response codes:
  code 200 -- 499

urls 文件中为测试网站的地址列表，每行只能一个。

2010年4月1日星期四

大型网站架构

FROM:

架构演变第一步: 物理分离 webserver和数据库

最开始, 由于某些想法, 于是在互联网上搭建了一个网站, 这个时候甚至有可能主机都是租借的, 但由于这篇文章我们只关注架构的演变历程, 因此就假设这个时候已经是托管了一台主机, 并且有一定的带宽了, 这个时候由于网站具备了一定的特色, 吸引了部分人访问, 逐渐你发现系统的压力越来越高, 响应速度越来越慢, 而这个时候比较明显的是数据库和应用互相影响, 应用出问题了, 数据库也很容易出现问题, 而数据库出问题的时候, 应用也容易出问题, 于是进入了第一步演变阶段: 将应用和数据库从物理上分离, 变成了两台机器, 这个时候技术上没有什么新的要求, 但你发现确实起到效果了, 系统又恢复到以前的响应速度了, 并且支撑住了更高的流量, 并且不会因为数据库和应用形成互相的影响.
看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:
这一步架构演变对技术上的知识体系基本没有要求.

架构演变第二步: 增加页面缓存

好景不长, 随着访问的人越来越多, 你发现响应速度又开始变慢了, 查找原因, 发现是访问数据库的操作太多, 导致数据连接竞争激烈, 所以响应变慢, 但数据库连接又不能开太多, 否则数据库机器压力会很高, 因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力, 这个时候首先也许会选择采用 squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然, 也可以采用将页面静态化的方案）, 这样程序上可以不做修改, 就能够很好的减少对 webserver的压力以及减少数据库连接资源的竞争, OK, 于是开始采用 squid来做相对静态的页面的缓存. 看看这一步完成后系统的图示:

这一步涉及到了这些知识体系: 前端页面缓存技术, 例如 squid, 如想用好的话还得深入掌握下 squid的实现方式以及缓存的失效算法等.

架构演变第三步: 增加页面片段缓存

增加了 squid做缓存后, 整体系统的速度确实是提升了, webserver的压力也开始下降了, 但随着访问量的增加, 发现系统又开始变的有些慢了, 在尝到了 squid之类的动态缓存带来的好处后, 开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢, 因此考虑采用类似 ESI之类的页面片段缓存策略, OK, 于是开始采用 ESI来做动态页面中相对静态的片段部分的缓存. 看看这一步完成后系统的图示:

这一步涉及到了这些知识体系: 页面片段缓存技术, 例如 ESI等, 想用好的话同样需要掌握 ESI的实现方式等；

架构演变第四步: 数据缓存

在采用ESI之类的技术再次提高了系统的缓存效果后, 系统的压力确实进一步降低了, 但同样, 随着访问量的增加, 系统还是开始变慢, 经过查找, 可能会发现系统中存在一些重复获取数据信息的地方, 像获取用户信息等, 这个时候开始考虑是不是可以将这些数据信息也缓存起来呢, 于是将这些数据缓存到本地内存, 改变完毕后, 完全符合预期, 系统的响应速度又恢复了, 数据库的压力也再度降低了不少. 看看这一步完成后系统的图示:

这一步涉及到了这些知识体系: 缓存技术, 包括像 Map数据结构、缓存算法、所选用的框架本身的实现机制等.

架构演变第五步: 增加 webserver

好景不长, 发现随着系统访问量的再度增加, webserver机器的压力在高峰期会上升到比较高, 这个时候开始考虑增加一台 webserver, 这也是为了同时解决可用性的问题, 避免单台的 webserver down机的话就没法使用了, 在做了这些考虑后, 决定增加一台 webserver, 增加一台 webserver时, 会碰到一些问题, 典型的有:

如何让访问分配到这两台机器上, 这个时候通常会考虑的方案是 Apache自带的负载均衡方案, 或 LVS这类的软件负载均衡方案；

如何保持状态信息的同步, 例如用户 session 等, 这个时候会考虑的方案有写入数据库、写入存储、 cookie或同步 session信息等机制等；

如何保持数据缓存信息的同步, 例如之前缓存的用户数据等, 这个时候通常会考虑的机制有缓存同步或分布式缓存；

如何让上传文件这些类似的功能继续正常, 这个时候通常会考虑的机制是使用共享文件系统或存储等；

在解决了这些问题后, 终于是把 webserver增加为了两台, 系统终于是又恢复到了以往的速度. 看看这一步完成后系统的图示:

这一步涉及到了这些知识体系: 负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、 linux 转发协议、所选用的技术的实现细节等）、主备技术（包括但不限于 ARP欺骗、 linux heart-beat等）、状态信息或缓存同步技术（包括但不限于 Cookie技术、 UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共享文件技术（包括但不限于 NFS等）、存储技术（包括但不限于存储设备等）.

架构演变第六步: 分库

享受了一段时间的系统访问量高速增长的幸福后, 发现系统又开始变慢了, 这次又是什么状况呢, 经过查找, 发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈, 导致了系统变慢, 这下怎么办呢, 此时可选的方案有数据库集群和分库策略, 集群方面像有些数据库支持的并不是很好, 因此分库会成为比较普遍的策略, 分库也就意味着要对原有程序进行修改, 一通修改实现分库后, 不错, 目标达到了, 系统恢复甚至速度比以前还快了. 看看这一步完成后系统的图示:

这一步涉及到了这些知识体系: 这一步更多的是需要从业务上做合理的划分, 以实现分库, 具体技术细节上没有其他的要求；但同时随着数据量的增大和分库的进行, 在数据库的设计、调优以及维护上需要做的更好, 因此对这些方面的技术还是提出了很高的要求的.

架构演变第七步: 分表、 DAL和分布式缓存

随着系统的不断运行, 数据量开始大幅度增长, 这个时候发现分库后查询仍然会有些慢, 于是按照分库的思想开始做分表的工作, 当然, 这不可避免的会需要对程序进行一些修改, 也许在这个时候就会发现应用自己要关心分库分表的规则等, 还是有些复杂的, 于是萌生能否增加一个通用的框架来实现分库分表的数据访问, 这个在 ebay的架构中对应的就是 DAL, 这个演变的过程相对而言需要花费较长的时间, 当然, 也有可能这个通用的框架会等到分表做完后才开始做, 同时, 在这个阶段可能会发现之前的缓存同步方案出现问题, 因为数据量太大, 导致现在不太可能将缓存存在本地, 然后同步的方式, 需要采用分布式缓存方案了, 于是, 又是一通考察和折磨, 终于是将大量的数据缓存转移到分布式缓存上了. 看看这一步完成后系统的图示:

这一步涉及到了这些知识体系: 分表更多的同样是业务上的划分, 技术上涉及到的会有动态 hash算法、 consistent hash算法等；DAL涉及到比较多的复杂技术, 例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的封装等；

架构演变第八步: 增加更多的 webserver

在做完分库分表这些工作后, 数据库上的压力已经降到比较低了, 又开始过着每天看着访问量暴增的幸福生活了, 突然有一天, 发现系统的访问又开始有变慢的趋势了, 这个时候首先查看数据库, 压力一切正常, 之后查看 webserver, 发现 apache 阻塞了很多的请求, 而应用服务器对每个请求也是比较快的, 看来是请求数太高导致需要排队等待, 响应速度变慢, 这还好办, 一般来说, 这个时候也会有些钱了, 于是添加一些 webserver服务器, 在这个添加 webserver服务器的过程, 有可能会出现几种挑战:

Apache的软负载或 LVS软负载等无法承担巨大的 web访问量（请求连接数、网络流量等）的调度了, 这个时候如果经费允许的话, 会采取的方案是购买硬件负载, 例如 F5、 Netsclar、 Athelon之类的, 如经费不允许的话, 会采取的方案是将应用从逻辑上做一定的分类, 然后分散到不同的软负载集群中；

原有的一些状态信息同步、文件共享等方案可能会出现瓶颈, 需要进行改进, 也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等；在做完这些工作后, 开始进入一个看似完美的无限伸缩的时代, 当网站流量增加时, 应对的解决方案就是不断的添加 webserver.

看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:
到了这一步, 随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高, 这个时候要求对所采用的技术都要有更为深入的理解, 并需要根据网站的需求来做更加定制性质的产品.

架构演变第九步: 数据读写分离和廉价存储方案

突然有一天, 发现这个完美的时代也要结束了, 数据库的噩梦又一次出现在眼前了, 由于添加的 webserver太多了, 导致数据库连接的资源还是不够用, 而这个时候又已经分库分表了, 开始分析数据库的压力状况, 可能会发现数据库的读写比很高, 这个时候通常会想到数据读写分离的方案, 当然, 这个方案要实现并不容易, 另外, 可能会发现一些数据存储在数据库上有些浪费, 或者说过于占用数据库资源, 因此在这个阶段可能会形成的架构演变是实现数据读写分离, 同时编写一些更为廉价的存储方案, 例如 BigTable这种. 看看这一步完成后系统的图示:

这一步涉及到了这些知识体系:
数据读写分离要求对数据库的复制、 standby等策略有深入的掌握和理解, 同时会要求具备自行实现的技术；廉价存储方案要求对 OS的文件存储有深入的掌握和理解, 同时要求对采用的语言在文件这块的实现有深入的掌握.

架构演变第十步: 进入大型分布式应用时代和廉价服务器群梦想时代

经过上面这个漫长而痛苦的过程, 终于是再度迎来了完美的时代, 不断的增加 webserver就可以支撑越来越高的访问量了, 对于大型网站而言, 人气的重要毋庸置疑, 随着人气的越来越高, 各种各样的功能需求也开始爆发性的增长, 这个时候突然发现, 原来部署在 webserver上的那个 web应用已经非常庞大了, 当多个团队都开始对其进行改动时, 可真是相当的不方便, 复用性也相当糟糕, 基本是每个团队都做了或多或少重复的事情, 而且部署和维护也是相当的麻烦, 因为庞大的应用包在 N台机器上复制、启动都需要耗费不少的时间, 出问题的时候也不是很好查, 另外一个更糟糕的状况是很有可能会出现某个应用上的 bug就导致了全站都不可用, 还有其他的像调优不好操作（因为机器上部署的应用什么都要做, 根本就无法进行针对性的调优）等因素, 根据这样的分析, 开始痛下决心, 将系统根据职责进行拆分, 于是一个大型的分布式应用就诞生了, 通常, 这个步骤需要耗费相当长的时间, 因为会碰到很多的挑战:

拆成分布式后需要提供一个高性能、稳定的通信框架, 并且需要支持多种不同的通信和远程调用方式；

将一个庞大的应用拆分需要耗费很长的时间, 需要进行业务的整理和系统依赖关系的控制等；

如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用.

经过这一步, 差不多系统的架构进入相对稳定的阶段, 同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量, 结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量.
看看这一步完成后系统的图示:

这一步涉及到了这些知识体系: 这一步涉及的知识体系非常的多, 要求对通信、远程调用、消息机制等有深入的理解和掌握, 要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解. 运维这块涉及的知识体系也非常的多, 多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等. 说起来确实不怎么费力, 整个网站架构的经典演变过程都和上面比较的类似, 当然, 每步采取的方案, 演变的步骤有可能有不同, 另外, 由于网站的业务不同, 会有不同的专业技术的需求, 这篇 blog更多的是从架构的角度来讲解演变的过程, 当然, 其中还有很多的技术也未在此提及, 像数据库集群、数据挖掘、搜索等, 但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、 CDN镜像等来支撑更大的流量, 因此在真实的发展过程中还会有很多的不同, 另外一个大型网站要做到的远远不仅仅上面这些, 还有像安全、运维、运营、服务、存储等, 要做好一个大型的网站真的很不容易, 写这篇文章更多的是希望能够引出更多大型网站架构演变的介绍.

数据库水平切分的实现原理解析－分库，分表，主从，集群，负载均衡器

作者：Ychon
网址: http://www.zhenhua.org/article.asp?id=685
关键字: 水平切分，分库，分表，主从，集群
第1章引言
随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（Java应用为例）：JDBC层的封装，ORM框架层的实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶段（beta版），其运行效率和生产时效性有待考究。就ORM框架层的实现而言，比如Taobao的基于ibatis和Spring的的分布式数据访问层，已有多年的应用，运行效率和生产实效性得到了开发人员和用户的肯定。本文就是以ORM框架层为基础而实现的分布式数据访问层。本课题的难点在于分库后，路由规则的制定和选择以及后期的扩展性，比如：如何做到用最少的数据迁移量，达到扩充数据库容量（增加机器节点）的目的。核心问题将围绕数据库分库分表的路由规则和负载均衡策略展开。
第2章基本原理和概念
2.1基本原理：
人类认知问题的过程总是这样的：what（什么）-?why(为什么)-?how(怎么
做)，接下来，本文将就这三个问题展开讨论和研究：
2.1.1什么是数据切分
"Shard" 这个词英文的意思是"碎片"，而作为数据库相关的技术用语，似乎最早见于大型多人在线角色扮演游戏中。"Sharding" 姑且称之为"分片"。Sharding 不是一门新技术，而是一个相对简朴的软件理念。众所周知，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢? 答案是：Sharding。 Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
通过一系列的切分规则将数据水平分布到不同的DB或table中，在通过相应的DB路由或者 table路由规则找到需要查询的具体的DB或者table，以进行Query操作。这里所说的“sharding”通常是指“水平切分”，这也是本文讨论的重点。具体将有什么样的切分方式呢和路由方式呢？行文至此，读者难免有所疑问，接下来举个简单的例子：我们针对一个Blog应用中的日志来说明，比如日志文章（article）表有如下字段：

面对这样的一个表，我们怎样切分呢？怎样将这样的数据分布到不同的数据库中的表中去呢？其实分析blog的应用，我们不难得出这样的结论：blog的应用中，用户分为两种：浏览者和blog的主人。浏览者浏览某个blog，实际上是在一个特定的用户的blog下进行浏览的，而blog的主人管理自己的blog，也同样是在特定的用户blog下进行操作的（在自己的空间下）。所谓的特定的用户，用数据库的字段表示就是“user_id”。就是这个“user_id”，它就是我们需要的分库的依据和规则的基础。我们可以这样做，将user_id为 1～10000的所有的文章信息放入DB1中的article表中，将user_id为10001～20000的所有文章信息放入DB2中的 article表中，以此类推，一直到DBn。这样一来，文章数据就很自然的被分到了各个数据库中，达到了数据切分的目的。接下来要解决的问题就是怎样找到具体的数据库呢？其实问题也是简单明显的，既然分库的时候我们用到了区分字段user_id，那么很自然，数据库路由的过程当然还是少不了 user_id的。考虑一下我们刚才呈现的blog应用，不管是访问别人的blog还是管理自己的blog，总之我都要知道这个blog的用户是谁吧，也就是我们知道了这个blog的user_id，就利用这个user_id，利用分库时候的规则，反过来定位具体的数据库，比如user_id是234，利用该才的规则，就应该定位到DB1，假如user_id是12343，利用该才的规则，就应该定位到DB2。以此类推，利用分库的规则，反向的路由到具体的DB，这个过程我们称之为“DB路由”。

当然考虑到数据切分的DB设计必然是非常规，不正统的DB设计。那么什么样的DB设计是正统的DB设计呢？
我们平常规规矩矩用的基本都是。平常我们会自觉的按照范式来设计我们的数据库，负载高点可能考虑使用相关的Replication机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的（下文会提及）。上面提到的“自觉的按照范式设计”。考虑到数据切分的DB设计，将违背这个通常的规矩和约束，为了切分，我们不得不在数据库的表中出现冗余字段，用作区分字段或者叫做分库的标记字段，比如上面的article的例子中的user_id这样的字段（当然，刚才的例子并没有很好的体现出user_id的冗余性，因为user_id这个字段即使就是不分库，也是要出现的，算是我们捡了便宜吧）。当然冗余字段的出现并不只是在分库的场景下才出现的，在很多大型应用中，冗余也是必须的，这个涉及到高效DB的设计，本文不再赘述。
2.1.2为什么要数据切分
上面对什么是数据切分做了个概要的描述和解释，读者可能会疑问，为什么需要数据切分呢？像 Oracle这样成熟稳定的数据库，足以支撑海量数据的存储与查询了？为什么还需要数据切片呢？的确，Oracle的DB确实很成熟很稳定，但是高昂的使用费用和高端的硬件支撑不是每一个公司能支付的起的。试想一下一年几千万的使用费用和动辄上千万元的小型机作为硬件支撑，这是一般公司能支付的起的吗？即使就是能支付的起，假如有更好的方案，有更廉价且水平扩展性能更好的方案，我们为什么不选择呢？
但是，事情总是不尽人意。平常我们会自觉的按照范式来设计我们的数据库，负载高点可能考虑使用相关的Replication机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的。首先它的有效很依赖于读操作的比例，Master往往会成为瓶颈所在，写操作需要顺序排队来执行，过载的话Master首先扛不住，Slaves的数据同步的延迟也可能比较大，而且会大大耗费CPU的计算能力，因为write操作在Master上执行以后还是需要在每台slave机器上都跑一次。这时候 Sharding可能会成为鸡肋了。 Replication搞不定，那么为什么Sharding可以工作呢？道理很简单，因为它可以很好的扩展。我们知道每台机器无论配置多么好它都有自身的物理上限，所以当我们应用已经能触及或远远超出单台机器的某个上限的时候，我们惟有寻找别的机器的帮助或者继续升级的我们的硬件，但常见的方案还是横向扩展, 通过添加更多的机器来共同承担压力。我们还得考虑当我们的业务逻辑不断增长，我们的机器能不能通过线性增长就能满足需求？Sharding可以轻松的将计算，存储，I/O并行分发到多台机器上，这样可以充分利用多台机器各种处理能力，同时可以避免单点失败，提供系统的可用性，进行很好的错误隔离。
综合以上因素，数据切分是很有必要的，且我们在此讨论的数据切分也是将MySql作为背景的。基于成本的考虑，很多公司也选择了Free且Open的MySql。对MySql有所了解的开发人员可能会知道，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢? 答案也是Sharding，也就是我们所说的数据切分方案。
我们用免费的MySQL和廉价的Server甚至是PC做集群，达到小型机+大型商业DB的效果，减少大量的资金投入，降低运营成本，何乐而不为呢？所以，我们选择Sharding，拥抱Sharding。
2.1.3怎么做到数据切分
说到数据切分，再次我们讲对数据切分的方法和形式进行比较详细的阐述和说明。
数据切分可以是物理上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。
数据切分也可以是数据库内的，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表，这样做的目的其实也是很简单的。举个例子说明，比如article表中现在有5000w条数据，此时我们需要在这个表中增加（insert）一条新的数据，insert完毕后，数据库会针对这张表重新建立索引，5000w行数据建立索引的系统开销还是不容忽视的。但是反过来，假如我们将这个表分成100 个table呢，从article_001一直到article_100，5000w行数据平均下来，每个子表里边就只有50万行数据，这时候我们向一张只有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的运行时效率，提高了DB的并发量。当然分表的好处还不知这些，还有诸如写操作的锁操作等，都会带来很多显然的好处。

综上，分库降低了单点机器的负载；分表，提高了数据操作的效率，尤其是Write操作的效率。行文至此我们依然没有涉及到如何切分的问题。接下来，我们将对切分规则进行详尽的阐述和说明。
上文中提到，要想做到数据的水平切分，在每一个表中都要有相冗余字符作为切分依据和标记字段，通常的应用中我们选用user_id作为区分字段，基于此就有如下三种分库的方式和规则：（当然还可以有其他的方式）
按号段分：
(1) user_id为区分，1～1000的对应DB1，1001～2000的对应DB2，以此类推；
优点：可部分迁移
缺点：数据分布不均
(2)hash取模分：
对user_id进行hash（或者如果user_id是数值型的话直接使用user_id 的值也可），然后用一个特定的数字，比如应用中需要将一个数据库切分成4个数据库的话，我们就用4这个数字对user_id的hash值进行取模运算，也就是user_id%4,这样的话每次运算就有四种可能：结果为1的时候对应DB1；结果为2的时候对应DB2；结果为3的时候对应DB3；结果为0的时候对应DB4，这样一来就非常均匀的将数据分配到4个DB中。
优点：数据分布均匀
缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据
(3)在认证库中保存数据库配置
就是建立一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的DB信息，然后才能进行我们需要的查询操作。
优点：灵活性强，一对一关系
缺点：每次查询之前都要多一次查询，性能大打折扣
以上就是通常的开发中我们选择的三种方式，有些复杂的项目中可能会混合使用这三种方式。通过上面的描述，我们对分库的规则也有了简单的认识和了解。当然还会有更好更完善的分库方式，还需要我们不断的探索和发现。
第3章本课题研究的基本轮廓
上面的文字，我们按照人类认知事物的规律，what?why?how这样的方式阐述了数据库切分的一些概念和意义以及对一些常规的切分规则做了概要的介绍。本课题所讨论的分布数据层并不仅仅如此，它是一个完整的数据层解决方案，它到底是什么样的呢？接下来的文字，我将详细阐述本研究课题的完整思想和实现方式。
分布式数据方案提供功能如下：
（1）提供分库规则和路由规则（RouteRule简称RR），将上面的说明中提到的三中切分规则直接内嵌入本系统，具体的嵌入方式在接下来的内容中进行详细的说明和论述；
（2）引入集群（Group）的概念，保证数据的高可用性；
（3）引入负载均衡策略（LoadBalancePolicy简称LB）；
（4）引入集群节点可用性探测机制，对单点机器的可用性进行定时的侦测，以保证LB策略的正确实施，以确保系统的高度稳定性；
（5）引入读/写分离，提高数据的查询速度；
仅仅是分库分表的数据层设计也是不够完善的，当某个节点上的DB服务器出现了宕机的情况的时候，会是什么样的呢？是的，我们采用了数据库切分方案，也就是说有N太机器组成了一个完整的DB ，如果有一台机器宕机的话，也仅仅是一个DB的N分之一的数据不能访问而已，这是我们能接受的，起码比切分之前的情况好很多了，总不至于整个DB都不能访问。一般的应用中，这样的机器故障导致的数据无法访问是可以接受的，假设我们的系统是一个高并发的电子商务网站呢？单节点机器宕机带来的经济损失是非常严重的。也就是说，现在我们这样的方案还是存在问题的，容错性能是经不起考验的。当然了，问题总是有解决方案的。我们引入集群的概念，在此我称之为Group，也就是每一个分库的节点我们引入多台机器，每台机器保存的数据是一样的，一般情况下这多台机器分摊负载，当出现宕机情况，负载均衡器将分配负载给这台宕机的机器。这样一来，
就解决了容错性的问题。所以我们引入了集群的概念，并将其内嵌入我们的框架中，成为框架的一部分。

如上图所示，整个数据层有Group1，Group2，Group3三个集群组成，这三个集群就是数据水平切分的结果，当然这三个集群也就组成了一个包含完整数据的DB。每一个Group包括1个Master（当然Master也可以是多个）和 N个Slave，这些Master和Slave的数据是一致的。比如Group1中的一个slave发生了宕机现象，那么还有两个slave是可以用的，这样的模型总是不会造成某部分数据不能访问的问题，除非整个 Group里的机器全部宕掉，但是考虑到这样的事情发生的概率非常小（除非是断电了，否则不易发生吧）。
在没有引入集群以前，我们的一次查询的过程大致如下：请求数据层，并传递必要的分库区分字段（通常情况下是user_id）?数据层根据区分字段Route到具体的DB?在这个确定的DB内进行数据操作。这是没有引入集群的情况，当时引入集群会是什么样子的呢？看图一即可得知，我们的路由器上规则和策略其实只能路由到具体的Group，也就是只能路由到一个虚拟的Group，这个Group并不是某个特定的物理服务器。接下来需要做的工作就是找到具体的物理的DB服务器，以进行具体的数据操作。基于这个环节的需求，我们引入了负载均衡器的概念（LB）。负载均衡器的职责就是定位到一台具体的DB服务器。具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强的操作的话，直接将查询负载分到Master，如果是读操作则通过负载均衡策略分配一个Slave。我们的负载均衡器的主要研究放向也就是负载分发策略，通常情况下负载均衡包括随机负载均衡和加权负载均衡。随机负载均衡很好理解，就是从N个Slave中随机选取一个Slave。这样的随机负载均衡是不考虑机器性能的，它默认为每台机器的性能是一样的。假如真实的情况是这样的，这样做也是无可厚非的。假如实际情况并非如此呢？每个Slave的机器物理性能和配置不一样的情况，再使用随机的不考虑性能的负载均衡，是非常不科学的，这样一来会给机器性能差的机器带来不必要的高负载，甚至带来宕机的危险，同时高性能的数据库服务器也不能充分发挥其物理性能。基于此考虑从，我们引入了加权负载均衡，也就是在我们的系统内部通过一定的接口，可以给每台DB服务器分配一个权值，然后再运行时LB根据权值在集群中的比重，分配一定比例的负载给该DB服务器。当然这样的概念的引入，无疑增大了系统的复杂性和可维护性。有得必有失，我们也没有办法逃过的。
有了分库，有了集群，有了负载均衡器，是不是就万事大吉了呢？事情远没有我们想象的那么简单。虽然有了这些东西，基本上能保证我们的数据层可以承受很大的压力，但是这样的设计并不能完全规避数据库宕机的危害。假如Group1中的slave2 宕机了，那么系统的LB并不能得知，这样的话其实是很危险的，因为LB不知道，它还会以为slave2为可用状态，所以还是会给slave2分配负载。这样一来，问题就出来了，客户端很自然的就会发生数据操作失败的错误或者异常。这样是非常不友好的！怎样解决这样的问题呢？我们引入集群节点的可用性探测机制，或者是可用性的数据推送机制。这两种机制有什么不同呢？首先说探测机制吧，顾名思义，探测即使，就是我的数据层客户端，不定时对集群中各个数据库进行可用性的尝试，实现原理就是尝试性链接，或者数据库端口的尝试性访问，都可以做到，当然也可以用JDBC尝试性链接，利用Java的Exception机制进行可用性的判断，具体的会在后面的文字中提到。那数据推送机制又是什么呢？其实这个就要放在现实的应用场景中来讨论这个问题了，一般情况下应用的DB 数据库宕机的话我相信DBA肯定是知道的，这个时候DBA手动的将数据库的当前状态通过程序的方式推送到客户端，也就是分布式数据层的应用端，这个时候在更新一个本地的DB状态的列表。并告知LB，这个数据库节点不能使用，请不要给它分配负载。一个是主动的监听机制，一个是被动的被告知的机制。两者各有所长。但是都可以达到同样的效果。这样一来刚才假设的问题就不会发生了，即使就是发生了，那么发生的概率也会降到最低。
上面的文字中提到的Master和Slave ，我们并没有做太多深入的讲解。如图一所示，一个Group由1个Master和N个Slave组成。为什么这么做呢？其中Master负责写操作的负载，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在 10：1左右，也就是说大量的数据操作是集中在读的操作，这也就是为什么我们会有多个Slave的原因。但是为什么要分离读和写呢？熟悉DB的研发人员都知道，写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上，而读操作其其他的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。读写分离也会引入新的问题，比如我的Master上的数据怎样和集群中其他的Slave机器保持数据的同步和一致呢?这个是我们不需要过多的关注的问题，MySql的Proxy机制可以帮助我们做到这点，由于Proxy机制与本课题相关性不是太强，
在这里不做详细介绍。
综上所述，本课题中所研究的分布式数据层的大体功能就是如此。以上是对基本原理的一些讨论和阐述。接下来就系统设计层面，进行深入的剖析和研究。
第4章系统设计
4.1系统实现层面的选择
在引言部分中提到，该系统的实现层面有两种选择，一种是基于JDBC层面上的选择，一种是基于现有数据持久层框架层面上的选择，比如Hibernate，ibatis。两种层面各有长处，也各有不足之处。基于JDBC层面上的系统实现，系统开发难度和后期的使用难度都将大大提高。大大增加了系统的开发费用和维护费用。本课题的定位是在成型的ibatis持久层框架的基础上进行上层的封装，而不是对ibatis源码的直接修改，这样一来使本系统不会对现有框架有太多的侵入性，从而也增加了使用的灵活性。之所以选择ibatis，原因如下：
（1）ibatis的学习成本非常低，熟练的Java Programmer可在非常的短时间内熟练使用ibatis；
（2）ibatis是轻量级的ORM，只是简单的完成了RO，OR的映射，其查询语句也是通过配置文件sql-map.xml文件在原生sql的层面进行简单的配置，也就是说我们没有引入诸如Hibernate那样的HQL的概念，从而增强了 sql的可控性，优秀的DBA可以很好的从sql的层面对sql进行优化，使数据层的应用有很强的可控性。Hibernate虽然很强大，但是由于 Hibernate是OR的一个重型封装，且引入HQL的概念，不便于DBA团队对sql语句的控制和性能的调优。
基于以上两点理由，本课题在ORM的产品的选择上选择了易学易用且轻量级的持久层框架ibatis。下面的讨论也都是特定于ibatis的基础上的讨论。
4.2其他开源框架的选择
在一些大型的Java应用中，我们通常会采用Spring这样的开源框架，尤其是 IoC（DI）这部分，有效的帮助开发人员管理对象的依赖关系和层次，降低系统各层次之间的实体耦合。Spring的优点和用处我相信这是开发人员众所周知的，在此不再赘述。本课题的数据层也将采用Spring做为IoC（DI）的框架。
4.3系统开发技术和工具介绍
开发语言：Java JDK1.5
集成开发环境：Eclipse 3.3.4
Web环境下测试服务器：JBoss 4.2
构建工具：淘宝自行研发的构建工具Antx（类似于Maven），当然也可以用Maven
依赖的开源Jar：Spring2.0，ibaits，commons-configuration(读取配置文件)，log4j，junit等

网站架构收集

生活在别处