分类归档: Arch

Facebook 的 Scaling Out 经验

Facebook 其实对待技术的态度其实挺开放的。今天阅读了这篇 Scale Out, 工程师 Jason Sobel 介绍了在对付跨地域 MySQL 复制网络延迟的问题。

Cache 一致性问题解决思路

大量的 MySQL + Memcached 服务器，布署简示：

California (主 Write/Read)............. Virginia (Read Only)

主数据中心在 California ，远程中心在 Virginia 。这两个中心网络延迟就有 70ms，MySQL 数据复制延迟有的时候会达到 20ms. 如果要让只读的信息从 Virginia 端发起，Memcached 的 Cache 数据一致性就是个问题。

1 用户发起更新操作，更名 "Jason" 到 "Monkey" ；
2 主数据库写入 "Monkey"，删除主、从两端 Memcached 中的名字值；
3 在 Virginia 有人查看该用户 Profile ；
4 在 Memcached 中没发现用户名字，从 Virginia  Slave 数据库读取，因为网络延迟，结果读到了 "Jason"；
5 更新 Virginia Memcached 中的该用户名字为 "Jason"；
6 复制追上了，更新名字为 ""Monkey"；
7 又有人读取 Profile 了；
8 在 Memcached 中找到了键值，返回 "Jason" （实际上造成业务冲突了)

解决办法挺有意思，在 SQL 解析层嵌入了针对 Memcached 的操作。

1 用户发起更新操作，更名 "Jason" 到 "Monkey" ；
2 主数据库写入 "Monkey"，删除主端 Memcached 中的名字值，但Virginia 端 Memcached 不删；(这地方在 SQL 解析上作了一点手脚，把更新的操作"示意"给远程)；
3 在 Virginia 有人查看该用户 Profile ；
4 在 Memcached 中找到键值，返回值 "Jason"；
5 复制追上更新 Slave 数据库用户名字为 "Monkey"，删除 Virginia Memcached 中的键值；
6 在 Virginia 有人查看该用户 Profile ；
7 Memcache 中没找到键值，所以从 Slave 中读取，然后得到正确的 "Monkey" 。

这里面的一个简单的原则是: 更新后的数据，用户第一次读取要从数据库读，顺便扔一份到 Cache 里，而不是在写入的时候直接更新 Memcached 。避免写事务过大。

而写操作的原则是：一次写入，到处分发。

第二个问题是关于”Page Routing”的，也很有参考价值。感兴趣的自己读一下吧。

–EOF–

另推荐一下: 分布式系统中的一致性和可用性，该文是上次在支付宝 QClub 活动的总结之二。

从 Flickr 的 DB 服务器配置说起 Swap

又读了一遍这个 PPT： Federation at Flickr: Doing Billions of Queries Per Day ，发现还是值得咀嚼一下，尽管这”甘蔗”已经被吃过了。

针对主机环境的实践参考

Flickr 数据库的硬件配置一般用 16G 内存，6块 15K 硬盘，RAID 10，在 EM64T 下跑 RHEL 4，运行在 Deadline I/O 调度器模式。回写 Cache 用控制器电池而不用磁盘的 Cache。Swappiness 设置为 0 . 。

大内存数据库服务器的 Swap 设置问题

上面提到了 Flickr 是把 Swappiness 设置为 0 ，简单的通过:

echo 0 > /proc/sys/vm/swappiness

个别情况下这样也可能没起作用，因为实际上对 Swap 的调用是由如下的公式计算得到的：

swap_tendency = mapped_ratio/2 + distress + vm_swappiness;

其中 vm_swappiness 默认值是 60.

这是个防御性的措施。Linux Kernel 2.6 （个别版本）有些诡异行为，当有大量物理内存空闲的时候，Linux 仍(或许)会傻乎乎的调用 Swap 空间，这导致有的时候系统性能很差。有人建议如果是 INNODB 的引擎的话，可以用 O_DIRECT 的方式强制直接调用物理内存。但似乎副作用很大（存疑)。

如果关闭 Swap (swapoff -a)的话，又会遇到 OOM 的问题。这是绝对不推荐的。

还有人用的方式是把 Swap 建立到 RAM 盘上。

Swap 的自动校正其实是个老问题，几年前可能超过 4g 的 Linux 服务器都不多，而现在动辄几十 G 的内存配置，应用场景发生了很大变化，Kernel 的算法思路肯定也要调整一些了吧(尽管几年来不断看到有小的 Patch 出来，可好像 RHEL 的 Kernel 还是老样子)。

我在这里抛砖引玉，大家实际应用中应该也遇到类似问题吧? 有什么建议? 还是干脆就不管? 默认情况下其实也能跑…

–EOF–

CAP：高可用架构的另一基石

在上周六的 QClub 上，BASE 成为了一个热点话题，其实除了这个 BASE 之外，还有个 CAP 理论也是值得关注一下的。这个概念也来自 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer ，应该说他 10 年前的那篇 Lessons from Internet Services: ACID vs. BASE 是互联网技术最为重要的一篇文章了。

C: Consistency 一致性 
A: Availability 可用性
P: Tolerance of network Partition 分区容忍性(有翻译为耐受性的，个人觉得不妥)

熊掌与鱼不可兼得，三个目标不能同时满足。如果对”一致性”要求高，且必需要做到”分区”，那么就要牺牲可用性；而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。

CAP 不是什么高深的东西，应该说 CAP 只是一个经验理论，切不可钻牛角尖，号称自己做的东西能打破 CAP 理论，那只是无意义的事情罢了。

如果知道 ACID(酸) 、BASE(碱) 在词典中的含义，那么这个 CAP 的辞典含义也很有趣。

–EOF–

最后推荐阅读一下这篇：可伸缩性原则

Alipay + QClub , 期待杭州侠客光临

本月 26 日，也就是明天，QClub：当SOA遭遇现实将如期在支付宝举行。

除了报名参加的杭州本地的众多技术精英，阿里集团各家子公司也都有人参加，淘宝、阿里软件、阿里妈妈都会有资深架构师到现场来。相信这回是一场精彩的思维碰撞，期待。

特邀嘉宾：支付宝首席架构师程立(花名：鲁肃)

程立，支付宝（中国）网络技术有限公司。2004年开始参与淘宝网与支付宝系统的建设，2005年起进入支付宝，一直从事于互联网电子支付系统的研发工作。现任支付宝首席架构师，专注于电子支付系统的分布式服务架构与开放架构。

一说起 SOA 可能很多人会觉得比较”空”，这也是我们举办会议的目的之一，”来点实在的技术信息” 是这次活动的一个宗旨。

会议地点

文三路、万塘路交汇处，华星时代广场 5 楼。大厅届时会有人指路

友情提示

为便于交流，请尽量携带名片 :)

–EOF–