1. 交互式游戏写操作很重

典型的Web应用读的操作比写操作多很多，所以很多通用架构并不适用于交互式游戏。读操作很重可以通过添加缓存来解决。写操作很重则需要进行数据分区以及采用基于内存的架构。

2. 每个模块都设计成独立的服务

独立开每个模块可以降低一个模块拖垮其他模块的概率。必要时可以停止一些功能以缓解系统压力。

3. 缓存Facebook数据

当严重依赖于外部模块时可以考虑通过缓存外部模块的数据来降低延迟。

4. 提前考虑新版本相关的使用高峰

5. 数据抽样

当分析海量数据的时候，可以通过数据抽样找到问题，不需要处理所有的数据。抽样数据同样可以找到问题而且能减少很大的工作量。

This benchmark test is to calculate processing time (real time) and file size of database. Writing test is to store 1,000,000 records. Reading test is to fetch all of its records. Both of the key and the value of each record are such 8-byte strings as `00000001′, `00000002′, `00000003′… Tuning parameters of each DBM are set to display its best performance. Platform: Linux 2.6.16 kernel, EXT3 file system (writeback), Intel Xeon quad core 2.3GHz CPU, 8GB RAM Compilation: gcc 4.2.3 (using -O3), glibc 2.7

Result

NAME	DESCRIPTION	WRITE TIME	READ TIME	FILE SIZE
TC	Tokyo Cabinet 1.3.5	0.402	0.334	42583208
QDBM	Quick Database Manager 1.8.77	2.779	0.962	56582932
NDBM	New Database Manager 5.1	5.118	3.551	834003968
SDBM	Substitute Database Manager 1.0.2	6.277	0	621281280
GDBM	GNU Database Manager 1.8.3	18.692	3.133	88137728
TDB	Trivial Database 1.0.6	7.219	0.789	52523008
CDB	Tiny Constant Database 0.75	0.357	0.371	40002048
BDB	Berkeley DB 4.6.21	9.108	3.109	41938944
TC-BT-ASC	B+ tree API of TC (ascending order)	0.707	0.601	32340739
TC-BT-RND	B+ tree API of TC (at random)	2.896	2.263	12532397
QDBM-BT-ASC	B+ tree API of QDBM (ascending order)	1.404	0.951	40620715
QDBM-BT-RND	B+ tree API of QDBM (at random)	6.311	3.816	15731675
BDB-BT-ASC	B+ tree API of BDB (ascending order)	1.354	1.451	57999360
BDB-BT-RND	B+ tree API of BDB (at random)	3.751	2.415	29818880
TC-FIXED	Fixed-length API of TC	0.248	0.037	9002452

via: http://tokyocabinet.sourceforge.net

Milo的创始人之一Ted Dziuba最近对Scalabitily又愤青了一把，大骂创业者或是开发人员不要在总想着系统的扩展性。对此，Ted喷出了三个论点：

1. People Who Talk Big About Scalability Don’t Need To Worry About It

很多Asshole没事就在博客中讨论可扩展性架构，但是自己却写着很烂的代码。好的系统不是靠构架就可以有扩展性的，一个有着很多N平方次循环的code是没有扩展性可言的。所以在你们大谈Memcached之前，先了解下缓存过期策略吧！

2. If You Haven’t Discussed Capacity Planning, You Can’t Discuss Scalability

你不需要去担心怎么扩展基于MySQL的程序，因为根本没人会去用你的应用。就算你有1000个用户，可能只有1%的用户会天天来使用你的系统。扩展系统不重要，重要的是怎么把人吸引过来。当然支撑百万用户的系统和千万用户的系统架构上是不同的，如果你设计的系统不会有100万用户，就不要太考虑扩展性了。

此外，工程师都会幻想着“线性扩展”，觉得如果用户太多，就加机器好了。其实根本没有这回事。去试试Amazon的SimpleDB吧，等你有了足够的用户并且数据存储的延时成为瓶颈时，就尽情的去骂”those shitty Amazon datacenters”吧。

3. Choosing Technology Don’t Mean Shit If You Don’t Know How To Use It

选择正确的技术不会完全解决扩展性问题。如何正确的使用才是王道。

最后引用Ted的话收场：Shut up about scalability, no one is using your app anyway.

注：文章中所涉及的所有脏话及不和谐用语皆为原文直接引用……

Bjorn Hansen的网站性能和可扩展性建议。基本上都是已知的东西。看来我们做的几个项目在这方面都是世界级的了。

Think Horizontally at every point in your architecture, not just at the web tier.

这句话很重要！

• Benchmarking
• 找好基准点
• Vertical scaling sucks.
• 垂直分割是很烂的
• Horizontal scaling rocks.
• 水平分割才是王道
• Run many application servers
• 运行多个应用服务器
• Don’t keep state in the app server
• 不要做应用服务器上保存状态
• Be stateless
• 系统要是无状态的
• Optimization is necessary, but is different than scalability.
• 优化是必要的，但不等同于扩展
• Cache things you hit all the time.
• 缓存所有命中的内容
• Measure, don’t assume, check.
• 测量、检查，不要假设
• Make pages static.
• 页面静态化
• aching is a trade-off.
• 缓存是双刃剑
• Cache full pages.
• 缓存整个页面
• Cache partial pages.
• 缓存部分页面
• Cache complex data.
• 缓存复杂数据 全文阅读 »

How Google Serves Data from Multiple Datacenters

Ryan Barrett, Google App Engine datastore lead, gave this talk Transactions Across Datacenters (and Other Weekend Projects) at the Google I/O 2009 conference.

While the talk doesn’t necessarily break new technical ground, Ryan does an excellent job explaining and evaluating the different options you have when architecting a system to work across multiple datacenters. This is called multihoming, operating from multiple datacenters simultaneously.

As multihoming is one of the most challenging tasks in all computing, Ryan’s clear and thoughtful style comfortably leads you through the various options. On the trip you learn:

The different multi-homing options are: Backups, Master-Slave, Multi-Master, 2PC, and Paxos. You’ll also learn how they each fair on support for consistency, transactions, latency, throughput, data loss, and failover.

Google App Engine uses master/slave replication between datacenters. They chose this approach in order to provide:
- lowish latency writes
- datacenter failure survival
- strong consistency guarantees.

No solution is all win, so a compromise must be made depending on what you think is important. A major Google App Engine goal was to provide a strong consistency model for programmers. They also wanted to be able to survive datacenter failures. And they wanted write performance that wasn’t too far behind a type relational database. These priorities guided their architectural choices.

In the future they hope to offer optional models so you can select Paxos, 2PC, etc for your particular problem requirements (Yahoo’s PNUTS does something like this).

There’s still a lot more to learn. Here’s my gloss on the talk:

全文阅读 »