MySQL Cluster是MySQL适合于分布式计算环境的高实用、高冗余版本。它采用了NDB Cluster存储引擎，允许在1个Cluster中运行多个MySQL服务器。

MySQL Cluster是一种技术，该技术允许在无共享的系统中部署“内存中”数据库的Cluster。通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬 件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。

总结了些移植到MySQL Cluster要注意的常见问题。

关于连接

MySQL集群适合用于高速带宽的环境中，采用TCP/IP方式 连接。它的性能跟主机间的连接速率有直接关系。集群中的最小速率要求是常规的100Mb以太网或者等同的网络。我们建议可能的话就采用G级网络。

关于内存

MySQL集群可以运行在任何启用NDB的平台上。显然，CPU 越快，内存越大，对集群性能提升越明显，64位的CPU也可能比32位的处理器更快。每个作为数据节点的机器都必须有足够的内存来保存共享数据库。

在MySQL 5.0中，集群只能基于内存。意思是所有表的数据(包括索引)都保存在内存中。如果你的数据有1GB那么大，你想要复制一份到集群中的话，那么就必须要 2GB的内存才行(每份复制占用1GB)，这是运行集群的计算机上相对其他操作系统额外要求的内存。

如果一个数据节点上的内存使用超出了可用的范围，则操作系统会使 用交换内存来达到上限值DataMemory。不过这会导致性能严重下降，并且可能导致相应时间变慢。正是由于这个原因，我们不推荐在生产环境中使用磁盘 交换空间。在任何情况下，只要达到DataMemory上限了，那么所有的操作请求(比如插入)都会失败。

在MySQL 5.1中实现了基于磁盘存储的集群，但是5.0中没有这个功能。对于包含主键哈希索引的有索引字段，必须仍保存在RAM中，但可以将所有其他字段保存在磁 盘上。

需要特别注意: 每个MySQL集群表都需要主键。如果没有定义主键，则 NDB 存储引擎会自动创建一个所有的数据节点的内存大小都要一样，由于集群中任何数据节点都不能使用比其他数据节点最小内存还多的内存。换句话说，如果集群中有 4台计算机，如果有3台计算机的内存都是3GB，而另外一台只有1GB，那么每个数据节点最多只能拿出1GB内存用于集群。

关于安全

MySQL集群的2个节点之间的通信是不安全的;它们没有经过任 何保护机制加密或者防护。安全的集群是放在防火墙之内的私网中，在外界中无法直接访问数据和管理节点(SQL节点也要和其他MySQL服务器一样注意安全 防护)。

关于存储引擎

MySQL集群只支持 NDB 存储引擎。也就是说，想要让一个表在集群节点中共享，就必须指定ENGINE=NDB(或 ENGINE=NDBCLUSTER 也一样)。

MySQL集群中也可以使用MyISAM或InnoDB存储引擎 来创建数据表，但是那些非NDB的表不会存储在集群节点间共享;它们独立于创建的MySQL服务器或者实例中。

关于导入

你可以把各种版本的MySQL数据导入到集群中去。唯一的要求就 是要导入的表必须是 NDB 存储引擎，也就是用 ENGINE=NDB 或 ENGINE=NDBCLUSTER方式创建的表。

关于数据类型

MySQL集群支持所有常用的数据类型，除了跟MySQL相关的 空间扩展类型(详情请看 Chapter 16， Spatial Extensions)。另外，NDB表的索引也有些不同。

注意: MySQL集群表(即 NDB 或 NDBCLUSTER 类型表)只支持固定长度记录。这也意味着(举例)如果有一条记录包含有 VARCHAR(255) 字段，那么它就会需要用到255个字符的空间(和数据表使用的字符集和校验所要求的空间一样大)，而不管实际存储的字符数。但是在MySQL 5.1中，只保存被记录实际占用的字段部分。

在NDB表中，数据库名称、表名称和属性名称不能与其他表处理程 序中的一样长。属性名称将被截短至31个字符，截短后如果不是唯一的，将导致错误。数据库名称和表名的总最大长度为122个字符（也就是说，NDB簇表名 的最大长度为122个字符减去该表所属的数据库的名称中的字符数）。

关于事务

NDB存储引擎的表都支持事务。在MySQL 5.0中，集群只支持READ COMMITTED隔离级别。

去年在对 SSD 做调查的时候就关注过这个五分钟法则，今天又发现了这 篇文章的修订版(为了纪念 Jim Gray），这个话题倒是可以简单介绍一下，对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。

在 1987 年，Jim Gray 与 Gianfranco Putzolu 发表了这个”五分钟法则”的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。 看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个”新的旧硬件”可能带来的影响。

随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。

根据数据结构和数据特点的不同，对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库，倾向于将 SSD 当作一致性存储来用。

这是一篇非常重要的文章(所以，建议读一下原文），其中对于数据库一节的描述尤其有趣（针对 DB 也有个五分钟)。限于篇幅，就不罗嗦了。

–EOF–

本文来自： http://www.dbanotes.net/arch/five-minute_rule.html

Memcached是danga.com（运营LiveJournal的技术团队）开发的一套分布式内存对象缓存系统，用于在动态系统中减 少数据库负载，提升性能。关于这个东西，相信很多人都用 过，本文意在通过对memcached的实现及代码分析，获得对这个出色的开源软件更深入的了解，并可以根据我们的需要对其进行更进一步的优化。末了将通 过对BSM_Memcache扩展的分析，加深对memcached的使用方式理解。

本文的部分内容可能需要比较好的数学基础作为辅助。

◎Memcached是什么

在阐述这个问题之前，我们首先要清楚它“不是什么”。很多人把它当作和SharedMemory那种形式的存储载体来使用，虽然memcached使用了 同样的“Key=>Value”方式组织数据，但是它和共享内存、APC等本地缓存有非常大的区别。Memcached是分布式的，也就是说它不是 本地的。它基于网络连接（当然它也可以使用localhost）方式完 成服务，本身它是一个独立于应用的程序或守护进程（Daemon方式）。

Memcached使用libevent库实现网络连接服务，理论上可以处理无限多的连接，但是它和Apache不同，它更多的时候是面向稳定的持续连接 的，所以它实际的并发能力是有限制的。在保守情况下memcached的最大同时连接数为200，这和Linux线程能力有关系，这个数值是可以调整的。关于libevent可以参考相关文档。 Memcached内存使用方式也和APC不同。APC是基于共享内存和MMAP的，memcachd有自己的内存分配算法和管理方式，它和共享内存没有 关系，也没有共享内存的限制，通常情况下，每个memcached进程可以管理2GB的内存空间，如果需要更多的空间，可以增加进程数。

◎Memcached适合什么场合

在很多时候，memcached都被滥用了，这当然少不了对它的抱怨。我经常在论坛上看见有人发贴，类似于“如何提高效率”，回复是 “用memcached”，至于怎么用，用在哪里，用来干什么一句没有。memcached不是万能的，它也不是适用在所有场合。

Memcached是“分布式”的内存对象缓存系统，那么就是说，那些不需要“分布”的，不需要共享的，或者干脆规模小到只有一台服务器的应 用，memcached不会带来任何好处，相反还会拖慢系统效率，因为网络连接同样需要资源，即使是UNIX本地连接也一样。 在我之前的测试数据中显示，memcached本地读写速度要比直接PHP内存数组慢几十倍，而APC、共享内存方式都和直接数组差不多。可见，如果只是本地级缓存，使用 memcached是非常不划算的。

Memcached在很多时候都是作为数据库前端cache使用的。因为它比数据库少了很多SQL解析、磁盘操作等开销，而且它是使用内存来管理数据的，所以它可以提供比直接读取数据库更好的性能，在 大型系统中，访问同样的数据是很频繁的，memcached可以大大降低数据库压力，使系统执行效率提升。另外，memcached也经常作为服务器之间 数据共享的存储媒介，例如在SSO系统中保存系统单点登陆状态的数据就可以保存在memcached中，被多个应用共享。

需要注意的是，memcached使用内存管理数据，所以它是易失的，当服务器重启，或者memcached进程中止，数据便会丢失，所以 memcached不能用来持久保存数据。很多人的错误理解，memcached的性能非常好，好到了内存和硬盘的对比程度，其实memcached使用 内存并不会得到成百上千的读写速度提高，它的实际瓶颈在于网络连接，它和使用磁盘的数据库系统相比，好处在于它本身非常“轻”，因为没有过多的开销和直接 的读写方式，它可以轻松应付非常大的数据交换量，所以经常会出现两条千兆网络带宽都满负荷了，memcached进程本身并不占用多少CPU资源的情况。

◎Memcached的工作方式

以下的部分中，读者最好能准备一份memcached的源代码。

Memcached是传统的网络服务程序，如果启动的时候使用了-d参数，它会以守护进程的方式执行。创建守护进程由daemon.c完成，这个程序只有 一个daemon函数，这个函数很简单（如无特殊说明，代码以1.2.1为准）：

1. #include

2. #include

3. #include

4. int

5. daemon(nochdir, noclose)

6. int nochdir, noclose;

7. {

8. int fd;

9. switch (fork()) {

10. case -1:

11. return (-1);

12. case 0:

13. break;

14. default:

15. _exit(0);

16. }

17. if (setsid() == -1)

18. return (-1);

19. if (!nochdir)

20. (void)chdir(“/”);

21. if (!noclose && (fd = open(“/dev/null”, O_RDWR, 0)) != -1) {

我们今天主要向大家介绍的是MySQL 集群，其中包括对MySQL 集群的概念介绍，以及如何在Server1与Server2上正确对MySQL进行安装 ，还有对安装与配置管理节点服务器(Server3)的正确操作 ，配置集群服务器并启动MySQL 。

一、介绍

这篇文档旨在介绍如何安装配置基于2台服务器的MySQL集群。并且实现任意一台服务器出现问题或宕机时MySQL依然能够继续运行。

注意！

虽然这是基于2台服务器的MySQL集群，但也必须有额外的第三台服务器作为管理节点，但这台服务器可以在集群启动完成后关闭。同时需要注意的是并 不推荐在集群启动完成后关闭作为管理节点的服务器。尽管理论上可以建立基于只有2台服务器的MySQL集群，但是这样的架构，一旦一台服务器宕机之后集群 就无法继续正常工作了，这样也就失去了集群的意义了。出于这个原因，就需要有第三台服务器作为管理节点运行。

另外，可能很多朋友都没有3台服务器的实际环境，可以考虑在VMWare或其他虚拟机中进行实验。

下面假设这3台服务的情况：

Server1: MySQL1.vmtest.net 192.168.0.1

Server2: MySQL2.vmtest.net 192.168.0.2

Server3: MySQL3.vmtest.net 192.168.0.3

Servers1和Server2作为实际配置MySQL集群的服务器。对于作为管理节点的Server3则要求较低，只需对Server3的系统 进行很小的调整并且无需安装MySQL，Server3可以使用一台配置较低的计算机并且可以在Server3同时运行其他服务。

二、在Server1和Server2上安装MySQL

从

注意：必须是max版本的MySQL，Standard版本不支持集群部署！

以下步骤需要在Server1和Server2上各做一次

    # mv MySQL-max-4.1.9-pc-linux-gnu-i686.tar.gz /usr/local/




    # cd /usr/local/




    # groupadd MySQL




    # useradd -g MySQL MySQL




    # tar -zxvf MySQL-max-4.1.9-pc-linux-gnu-i686.tar.gz




    # rm -f MySQL-max-4.1.9-pc-linux-gnu-i686.tar.gz




    # mv MySQL-max-4.1.9-pc-linux-gnu-i686 MySQL




    # cd MySQL




    # scripts/MySQL_install_db --user=MySQL




    # chown -R root .




    # chown -R MySQL data




    # chgrp -R MySQL .




    # cp support-files/MySQL.server /etc/rc.d/init.d/MySQLd




    # chmod x /etc/rc.d/init.d/MySQLd




    # chkconfig --add MySQLd

此时不要启动MySQL！

1．  先了解一下你是否应该用 mysql 集群。

减少数据中心结点压力和大数据量处理，采用把 mysql 分布，一个或多个 application 对应一个 mysql 数据库。把几个 mysql 数据库公用的数据做出共享数据，例如购物车，用户对象等等，存在数据结点里面。 其他不共享的数据还维持在各自分布的 mysql 数据库本身中。

2．  集群 Mysql 中名称概念 .( 如上图 )

1 ） Sql 结点（ SQL node– 上图对应为 mysqld ） : 分布式数据库。包括自身数据和查询中心结点数据 .

2 ）数据结点 (Data node — ndbd): 集群共享数据 ( 内存中 ).

3 ）管理服务器 (Management Server – ndb_mgmd): 集群管理 SQL node,Data node.

3 ．配置

mysql-max 版本，当然现在 mysql 集群系统 windonws 平台上面不被支持 .

安装 mysql 就不多说了，网上一打堆，简明扼要。

A:192.168.1.251 – Data node 和 Management Server.

在为某证券公司设计其OA架构时，初期客户是30万用户在线；然而在项目实施中，客户又提出50万用户同时在线的需求，而且都有写的需求；这样初始的设计 master-master-slave，读写分离满足不了客户的要求，所以我们打算采用Mysql Cluster方案；MySQL Cluster 是MySQL适合于分布式计算环境的高实用、高冗余版本。它采用了NDB Cluster 存储引擎，允许在1个Cluster中运行多个MySQL服务器。在MyQL 5.0及以上的二进制版本中、以及与最新的Linux版本兼容的RPM中提供了该存储引擎。

一、MySQL Cluster概述

MySQL Cluster 是一种技术，该技术允许在无共享的系统中部署“内存中”数据库的 Cluster 。通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。

MySQL Cluster 由一组计算机构成，每台计算机上均运行着多种进程，包括MySQL服务器，NDB Cluster 的数据节点，管理服务器，以及（可能）专门的数据访问程序。

所有的这些节点构成一个完成的MySQL集群体系。数据保存在“NDB存储服务器”的存储引擎中，表（结构）则保存在“MySQL服务器”中。应用程序通 过“MySQL服务器”访问这些数据表，集群管理服务器通过管理工具(ndb_mgmd)来管理“NDB存储服务器”。

通过将MySQL Cluster 引入开放源码世界，MySQL为所有需要它的人员提供了具有高可用性、高性能和可缩放性的 Cluster 数据管理。

二、MySQL Cluster 基本概念

“NDB” 是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点。

MySQL Cluster 能够使用多种故障切换和负载平衡选项配置NDB存储引擎，但在 Cluster 级别上的存储引擎上做这个最简单。MySQL Cluster的NDB存储引擎包含完整的数据集，仅取决于 Cluster本身内的其他数据。

目前，MySQL Cluster的 Cluster部分可独立于MySQL服务器进行配置。在MySQL Cluster中， Cluster的每个部分被视为1个节点。

管理(MGM)节点：这类节点的作用是管理MySQL Cluster内的其他节点，如提供配置数据、启动并停止节点、运行备份等。由于这类节点负责管理其他节点的配置，应在启动其他节点之前首先启动这类节 点。MGM节点是用命令“ndb_mgmd”启动的。

数据节点：这类节点用于保存 Cluster的数据。数据节点的数目与副本的数目相关，是片段的倍数。例如，对于两个副本，每个副本有两个片段，那么就有4个数据节点。不过没有必要设 置多个副本。数据节点是用命令“ndbd”启动的。

SQL节点：这是用来访问 Cluster数据的节点。对于MySQL Cluster，客户端节点是使用NDB Cluster存储引擎的传统MySQL服务器。通常，SQL节点是使用命令“mysqld –ndbcluster”启动的，或将“ndbcluster”添加到“my.cnf”后使用“mysqld”启动。

注释：在很多情况下，术语“节点”用于指计算机，但在讨论MySQL Cluster时，它表示的是进程。在单台计算机上可以有任意数目的节点，为此，我们采用术语“ Cluster主机”。

管理服务器(MGM节点)负责管理 Cluster配置文件和 Cluster日志。 Cluster中的每个节点从管理服务器检索配置数据，并请求确定管理服务器所在位置的方式。当数据节点内出现新的事件时，节点将关于这类事件的信息传输 到管理服务器，然后，将这类信息写入 Cluster日志。

此外，可以有任意数目的 Cluster客户端进程或应用程序。它们分为两种类型： 标准MySQL客户端：对于MySQL Cluster，它们与标准的（非 Cluster类）MySQL没有区别。换句话讲，能够从用PHP、Perl、C、C++、Java、Python、Ruby等编写的现有MySQL应用 程序访问MySQL Cluster。

如果用户想改变表的默认字符集和所有的字符列的字符集到一个新的字符集，使用下面的语句： ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name;

警告： 上述操作是在字符集中转换列值。如果 用户在字符集（如 gb2312）中有一个列，但存储的值使用的是其它的一些不兼容的字符集（如 utf8），那么该操作将不会得到用户期望的结果。在这种情况下，用户必须对每一列做如下操作：

ALTER TABLE t1 CHANGE c1 c1 BLOB; ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;

这样做的原因是：从 BLOB 列转换或转换到 BLOB 列没有转换发生。

如果用户指定以二进制进行 CONVERT TO CHARACTER SET，则 CHAR、VARCHAR 和 TEXT 列将转换为它们对应的二进制字符串类型（BINARY，VARBINARY，BLOB）。这意味着这些列将不再有字符集，随后的 CONVERT TO 操作也将不会作用到它们上。

如果仅仅改变一个表的缺省字符集，可使用下面的语句：

ALTER TABLE tbl_name DEFAULT CHARACTER SET charset_name;

DEFAULT是可选的。当向一个表里添 加一个新的列时，如果没有指定字符集，则就采用缺省的字符集（例如当ALTER TABLE … ADD column）。

ALTER TABLE … DEFAULT CHARACTER SET 和 ALTER TABLE … CHARACTER SET 是等价的，修改的仅仅是缺省的表字符集。

InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等 高级处 理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已 经外部键等高级数据库功能。

MyIASM是IASM表的新版本，有如下扩展：

1、二进制层次的可移植性。

2、NULL列索引。

3、对变长行比ISAM表有更少的碎片。

4、支持大文件。

5、更好的索引压缩。

6、更好的键码统计分布。

7、更好和更快的auto_increment处理。

InnoDB 是 MySQL 上第一个提供外键约束的引擎，除了提供事务处理外，InnoDB 还支持行锁，提供和 Oracle 一样的一致性的不加锁读取，能增加并发读的用户数量并提高性能，不会增加锁的数量。

InnoDB 的设计目标是处理大容量数据时最大化性能，它的 CPU 利用率是其他所有基于磁盘的关系数据库引擎中最有效率的。

InnoDB 是一套放在 MySQL 后台的完整数据库系统，InnoDB 有它自己的缓冲池，能缓冲数据和索引，InnoDB 还把数据和索引存放在表空间里面，可能包含好几个文件，这和 MyISAM 表完全不同，在 MyISAM 中，表被存放在单独的文件中，InnoDB 表的大小只受限于操作系统文件的大小，一般为 2GB。

以下是一些细节和具体实现的差别：

1、InnoDB不支持FULLTEXT类型的索引。

2、InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。

3、对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。

4、DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。

5、LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外 的InnoDB特性（例如外键）的表不适用。

6、InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”

MyISAM和InnoDB优化：

key_buffer_size – 这对MyISAM表来说非常重要。如果只是使用MyISAM表，可以把它设置为可用内存的 30-40%。合理的值取决于索引大小、数据量以及负载 — 记住，MyISAM表会使用操作系统的缓存来缓存数据，因此需要留出部分内存给它们，很多情况下数据比索引大多了。尽管如此，需要总是检查是否所有的 key_buffer 都被利用了 — .MYI 文件只有 1GB，而 key_buffer 却设置为 4GB 的情况是非常少的。这么做太浪费了。如果你很少使用MyISAM表，那么也保留低于 16-32MB 的 key_buffer_size 以适应给予磁盘的临时表索引所需。

portupgrade 是一个软件，用于快捷便利地升级软件,安装办法:

#cd /usr/ports/sysutils/portupgrade

#make install clean

然后用cvsup更新ports树，最后运行:

#portupgrade -r pkg_name 升级单个软件和与其相关的,其中 pkg_name 是 pkg_info 中显示的名字

portupgrade -ar 就会自动更新全部了。

如果加上 P 参数，则先看是否有已经编译好的 pkg 下载，直接从 pkg 升级，省去自己编译。

下载站点可以通过修改 /usr/local/etc/pkgtools.conf 更改。

portupgrade -arR 升级所有已经安装的软件，并且检查依赖关系。

Five Minutes 公司程延辉（小名康天） 介绍开心农场架构，social game的技术挑战，支持千万级DAU的social game技术架构。这是一个对于开发者来说，非常精彩，非常有实用性指导的一次演讲，详细介绍了很多技术内幕。

»猛击这里下载演讲ppt«

Five Minutes 公司的著名social game 开心农场，目前非常受用户欢迎，包括国外的Facebook，国内的开心网都是如此，是全球最大的social game，台下热烈掌声。呵呵。开心农场这个游戏从介绍看，相当成功，最早是08年9月在xiaonei上线，而后在51等平台推广，包括Facebook。现在已经有1570万游戏用户了，其中包括50万的Facebook用户。

开心农场架构主要难点：1。如何存储大规模的用户数据千万级2。如果应对大量访问每天数亿请求量3。如果应对数据的频繁修改，每秒数万次数据修改。

解决的方式

优化：

1。负载均衡，web服务器平行扩展。

2。服务器性能优化。

3。异步处理，缓存数据接口，Linux内核参数优化，挖掘PHP的效率，用fastcgi模式运行php，用EAccelerator加速。固定不变数据做成php配置文件，用C开发PHP扩展等。

数据库性能优化：

1。数据库分库分表，所有数据全部设计成 key－》value形式，不用join。

2。使用INNODB，经常操作的数据表中所有字段尽量设计成数值型，用update替代INSERT和DELETE操作

异步处理：整个系统最关键的部分，

原则：把客户端暂时不需要的数据进行异步处理。

实例：讲非核心数据先写入memcached，异步更新到数据库，合并数据库更新操作，Feed和Notification的异步发送。

利用客户端资源：Flash屏蔽重复操作和不必要请求，Flash进行一些计算减轻服务器的复旦，例如好友排序等。Flash缓存一些数据。

social game ＝ social ＋ game。实时互动（大负载）和非实时互动（大负载）。

服务器角色：场景服务器，逻辑服务器，admin服务器，gateway，架构逻辑还是挺复杂的，每天处理亿级请求的架构，完全和百万级不一样！完全能够通过平行扩展的方式应对，gateway和场景服务器都完全可以增加。

Blue Whale是他们们正在开发的解决长连接的social game架构。

开心农场在现场招聘：需要C++,Python， Flash AS3程序员。

程延辉的演讲获得了在场热烈的掌声。

假设有一个表，结构如下：

mysql> CREATE TABLE `a` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `id2` int(10) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=MyISAM;

该表中只有6条记录，如下：

mysql> select * from a;
+----+---------+
| id | city_id |
+----+---------+
|  2 |       2 |
|  3 |       3 |
|  5 |       5 |
|  4 |       4 |
|  6 |       6 |
|  7 |       7 |
+----+---------+
注意上面id的显示顺序，由于没有指定排序字段，myisam表引擎是随机显示记录列表的。
现在想要把id字段分别-1，执行以下语句，得到报错：

mysql> update a set id=id-1;
ERROR 1062 (23000): Duplicate entry '4' for key 'PRIMARY'

看看更新后的结果，可以看到：

注：此文首发于 《程序员》杂志 2008 年 7 月刊。

从 Shard 到 Sharding

“Shard” 这个词英文的意思是”碎片”，而作为数据库相关的技术用语，似乎最早见于大型多人在线角色扮演游戏(MMORPG)中。”Sharding” 姑且称之为”分片”。

Sharding 不是一门新技术，而是一个相对简朴的软件理念。如您所知，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢? 答案是：Sharding。

Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。

事关数据库扩展性

说起数据库扩展性，这是个非常大的话题。目前的商业数据都有自己的扩展性解决方案，在过去相对来说比较成熟，但是随着互联网的高速发展，不可避免的会带来一些计算模式上的演变，这样很多主流商业系统也难免暴露出一些不足之处。比如 Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 Scale Up（向上扩展） 类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。

Sharding 基本上是针对开源数据库的扩展性解决方案，很少有听说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱 Scale Out，逐渐从 Scale Up 中解放出来。

Sharding 的应用场景

任何技术都是在合适的场合下能发挥应有的作用。 Sharding 也一样。联机游戏、IM、BSP 都是比较适合 Sharding 的应用场景。其共性是抽象出来的数据对象之间的关联数据很小。比如IM ，每个用户如果抽象成一个数据对象，完全可以独立存储在任何一个地方，数据对象是 Share Nothing 的；再比如 Blog 服务提供商的站点内容，基本为用户生成内容(UGC)，完全可以把不同的用户隔离到不同的存储集合，而对用户来说是透明的。

这个 “Share Nothing” 是从数据库集群中借用的概念，举例来说，有些类型的数据粒度之间就不是 “Share Nothing” 的，比如类似交易记录的历史表信息，如果一条记录中既包含卖家信息与买家信息，如果随着时间推移，买、卖家会分别与其它用户继续进行交易，这样不可避免的两个买卖家的信息会分布到不同的 Sharding DB 上，而这时如果针对买卖家查询，就会跨越更多的 Sharding ，开销就会比较大。

现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解，抛砖引玉，以期能引出更具价值的信息。

事关图片的存储

把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备，那么简单的很；如果有能力自己开发单独存储图片的文件系统，那么也不用接着往下看了。

如果上述条件不具备，只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的，实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ，怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑，选择合适大小的 inode size ，在空间和速度上做取舍，同时防患于未然，注意单个文件系统下文件个数别达到极限。

独立，独立的服务器

无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。

如果不想在几台机器间同步所有图片，只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题，以及 NFS 特定的传输速度。

独立，独立的域名

如果大部分 Web 页面必须要载入很多图片，那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。

前几天有个朋友在线上问我，”一些大网站，图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?” ，粗糙一点的答案：除了管理方便，便于CDN 同步处理，上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知，有请 Yahoo！的同学发言) 【还有一个我没考虑到的是 Cookie 的因素，参加楼下高春辉的留言】

雅虎 Web 优化 14 条

关于雅虎 YSlow 工具倡导的 优化 14 条规则，建议每个 Web 维护人员必须倒背如流，当然也应该辩证来看–介绍这 14 条规则的页面本身也只能得到 70 多分…其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。

到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。

如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。

拥抱熟知的技术

动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。

架构层次清晰化

起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB

层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好–一般人儿我不告诉他…不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要

很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要

因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。

功能增加要谨慎

不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。

有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能

这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的

这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：

发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)

有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是”业务不允许”的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。

这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。

—EOF—

• 好的业务模式(产品) + 很好的技术 = 大赚钱
• 好的业务模式(产品) + 能用的技术 = 也赚钱
• 差的业务模式(产品) + 好的技术 = 赚吆喝(现在的SNS就差不多这样了)
• 差的业务模式(产品) + 差的技术 = 自己浪费资源

VPS下lighttpd配置DiscuzX伪静态规则

第一步：进入Kloxo VPS控制面板点击域名选项. 第二步：进入域名选项后，选中你所要配置lighttpd的DiscuzX伪静态规则的域名， 这里所需要配置的域名为找iPad论坛 www.cn0393.com , 点击它，进入站点选项列表. 第三步：点击lighttpd地址重写规则按纽,进入lighttpd配置界面. 第四步：把由找ipad论坛提供的lighttpd的DiscuzX伪静态规则文件粘贴进空白框中. 第五步：然后点击Update按纽，应用并使lighttpd生效.         注：lighttpd会自动重启可以不用像IIS那样需要手工重启。 第六步：进入DiscuzX管理中心，点击–》全局–》优化设置–》URL静态化         把箭头所指的勾全选中–》点提交 最后一步，就是更新一下缓存就OK了，超简单。哥你懂的，就不截图了。自已看效果吧！