数据库优化的实现 前面提到的一个数据库节点为Shard，一个Shard由两个台物理服务器组成， 可以理解为Node-A和Node-B，Node-A和Node-B之间是配置成Master-Master相互复制的。 虽然是Master-Master的部署方式，但是同一时间还是只使用其中一个，原因是复制的延迟问题， 当然在Web应用里，可以在用户会话里放置一个A或B来保证同一用户一次会话里只访问一个数据库， 这样可以避免一些延迟问题。但是Python任务是没有任何状态的，不能保证和PHP应用读写相同的数据库。那么为什么不配置成Master-Slave 呢？Yupoo觉得只用一台太浪费了，所以在每台服务器上都创建多个逻辑数据库。 如下图所示，在Node-A和Node-B上我们都建立了shard_001和shard_002两个逻辑数据库， Node-A上的shard_001和Node-B上的shard_001组成一个Shard，而同一时间只有一个逻辑数据库处于Active状态。 这个时候如果需要访问Shard-001的数据时，我们连接的是Node-A上的shard_001， 而访问Shard-002的数据则是连接Node-B上的shard_002。以这种交叉的方式将压力分散到每台物理服务器上。 以Master-Master方式部署的另一个好处是，可以不停止服务的情况下进行表结构升级， 升级前先停止复制，升级Inactive的库，然后升级应用，再将已经升级好的数据库切换成Active状态， 原来的Active数据库切换成Inactive状态，然后升级它的表结构，最后恢复复制。 当然这个步骤不一定适合所有升级过程，如果表结构的更改会导致数据复制失败，那么还是需要停止服务再升级的。
前面提到过添加服务器时，为了保证负载的平衡，需要迁移一部分数据到新的服务器上。为了避免短期内迁移的必要，在实际部 署的时候，每台机器上部署了8个逻辑数据库， 添加服务器后，只要将这些逻辑数据库迁移到新服务器就可以了。最好是每次添加一倍的服务器， 然后将每台的1/2逻辑数据迁移到一台新服务器上，这样能很好的平衡负载。当然，最后到了每台上只有一个逻辑库时，迁移就无法避免了，不过那应该是比较久 远的事情了。 Yupoo把分库逻辑都封装在我们的PHP框架里了，开发人员基本上不需要被这些繁琐的事情困扰。下面是使用框架进行照片数据的读写的一些例子： array('type' => 'long', 'primary' => true, 'global_auto_increment' => true),
'user_id' => array('type' => 'long'),
'title' => array('type' => 'string'),
'posted_date' => array('type' => 'date'),
));
$photo = $Photos->new_object(array('user_id' => 1, 'title' => 'Workforme'));
$photo->insert();
// 加载ID为10001的照片，注意第一个参数为用户ID
$photo = $Photos->load(1, 10001);
// 更改照片属性
$photo->title = 'Database Sharding';
$photo->update();
// 删除照片
$photo->delete();
// 获取ID为1的用户在2010-06-01之后上传的照片
$photos = $Photos->fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01'));
?>首先要定义一个ShardedDBTable对象，所有的API都是通过这个对象开放。第一个参数是对象类型名称， 如果这个名称已经存在，那么将返回之前定义的对象。你也可以通过get_table(‘Photos’)这个函数来获取之前定义的Table对象。 第二个参数是对应的数据库表名，而第三个参数是数据库线索字段，你会发现在后面的所有API中全部需要指定这个字段的值。 第四个参数是字段定义，其中photo_id字段的global_auto_increment属性被置为true，这就是前面所说的全局自增ID， 只要指定了这个属性，框架会处理好ID的事情。 如果我们要访问全局库中的数据，我们需要定义一个DBTable对象。 array('type' => 'long', 'primary' => true, 'auto_increment' => true),
'username' => array('type' => 'string'),
));
?>DBTable是ShardedDBTable的父类，除了定义时参数有些不同（DBTable不需要指定数据库线索字段），它们提供一样的API。 六、缓存方案的选择 Yupoo使用的框架自带缓存功能，对开发人员是透明的。 load(1, 10001); ?> 比如上面的方法调用，框架先尝试以Photos-1-10001为Key在缓存中查找，未找到的话再执行数据库查询并放入缓存。当更改照片属性或删除照片时，框架负责从缓存中删除该照片。这种单个对象的缓存实现起来比较简单。稍微麻烦的是像下面这样的列表查询结果的缓存。 fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01'));
?>Yupoo把这个查询分成两步，第一步先查出符合条件的照片ID，然后再根据照片ID分别查找具体的照片信息。 这么做可以更好的利用缓存。第一个查询的缓存Key为Photos-list-{shard_key}-{md5(查询条件SQL语句)}， Value是照片ID列表（逗号间隔）。其中shard_key为user_id的值1。目前来看，列表缓存也不麻烦。 但是如果用户修改了某张照片的上传时间呢，这个时候缓存中的数据就不一定符合条件了。所以，需要一个机制来保证我们不会从缓存中得到过期的列表数据。我们 为每张表设置了一个revision，当该表的数据发生变化时（调用insert/update/delete方法）， 我们就更新它的revision，所以我们把列表的缓存Key改为Photos-list-{shard_key}-{md5(查询条件SQL语 句)}-{revision}， 这样我们就不会再得到过期列表了。 revision信息也是存放在缓存里的，Key为Photos-revision。这样做看起来不错，但是好像列表缓 存的利用率不会太高。因为我们是以整个数据类型的revision为缓存Key的后缀，显然这个revision更新的非常频繁，任何一个用户修改或上传 了照片都会导致它的更新，哪怕那个用户根本不在我们要查询的Shard里。要隔离用户的动作对其他用户的影响，我们可以通过缩小revision的作用范 围来达到这个目的。 所以revision的缓存Key变成Photos-{shard_key}-revision，这样的话当ID为1的用户修改了他的照片信息时， 只会更新Photos-1-revision这个Key所对应的revision。 因为全局库没有shard_key，所以修改了全局库中的表的一行数据，还是会导致整个表的缓存失效。 但是大部分情况下，数据都是有区域范围的，比如帮助论坛的主题帖子， 帖子属于主题。修改了其中一个主题的一个帖子，没必要使所有主题的帖子缓存都失效。 所以在DBTable上增加了一个叫isolate_key的属性。 array('type' => 'long', 'primary' => true),
'post_id' => array('type' => 'long', 'primary' => true, 'auto_increment' => true),
'author_id' => array('type' => 'long'),
'content' => array('type' => 'string'),
'posted_at' => array('type' => 'datetime'),
'modified_at' => array('type' => 'datetime'),
'modified_by' => array('type' => 'long'),
), 'topic_id');
?>注意构造函数的最后一个参数topic_id就是指以字段topic_id作为isolate_key，它的作用和shard_key一样用于隔离revision的作用范围。 ShardedDBTable继承自DBTable，所以也可以指定isolate_key。 ShardedDBTable指定了isolate_key的话，能够更大幅度缩小revision的作用范围。 比如相册和照片的关联表yp_album_photos，当用户往他的其中一个相册里添加了新的照片时， 会导致其它相册的照片列表缓存也失效。如果指定这张表的isolate_key为album_id的话， 我们就把这种影响限制在了本相册内。 缓存分为两级，第一级只是一个PHP数组，有效范围是Request。而第二级是memcached。这么做的原因是， 很多数据在一个Request周期内需要加载多次，这样可以减少memcached的网络请求。另外Yupoo的框架也会尽可能的发送memcached 的gets命令来获取数据， 从而减少网络请求。 参考文章：http://www.infoq.com/cn/articles/yupoo-partition-database |
