high scalability网站上all-time-favorites聚合下的文章的阅读笔记

大部分文章似乎有点老了，不知道现在FB、Tumblr、Pinterest、Twitter这些网站的架构是什么样子的了。

1、clustering vs sharding？自动/手动（需要去除join，添加cache，NoSQL似乎不如MySQL成熟？但HBase/Cassandra似乎又还可以）

2、技术为业务服务，架构为应用服务，so创新在于发现真正的有价值的问题（需求）

3、应用特定的数据库？物化“数据项”，无锁事务，append-only存储；为大规模scale设计：普通FS -> ceph/...（分布式对象数据库）

4、LB：缩短用户与“内容”之间的路径

5、howto protect data？howto USE them？

6、User table（存储用户信息的表）is not sharded.

7、shard with 大容量规划（means ‘hash big’）<-- add timestamp to hash key？

8、Mapping（分片/存储）& reverse-mapping（query）

9、cache：memcache/redis（支持的数据结构更丰富点）——不知道现在memcached功能是否完善了？

10、Scripting：sharding过滤器方案，迁移数据（not so good）

11、Pyres：Python over redis？（Resque -->）

12、Dev：everyone has access to everything, be careful.（统一的全局视图）小型团队用git可能并不合适，git vs svn有时候只是操作大型repo的性能原因

13、SOA：实际的db proxy也是一个服务！

14、Keep it simple & fun

15、Architect is doing the right thing，if growth can be handled by adding more of the same stuff.（水平扩展）

16、不要害怕（？）丢失部分数据，根据data性质决定CAP/BASE

17、Master-slave lag（主从复制的缺点）：当然主-主复制又会引入分布式一致性问题，一开始就应该shard writes（如何真正地做无join的设计？靠增加冗余吗？）

18、keep load at <= 50%（live容量须可控）（或“留出resilience”）

19、use tool，not framework（前者意味着小型可组合，后者实际上属于侵入式设计，比如那个恶心的Spring）

20、避免（分布式下的）joins：de-normalize？从一开始就设计为可扩展/“伸展性”

21、把网站变为服务（API）：twitter早期的成功做法

22、防止abuse

23、Cache vs Log：注意两者相似的地方，Cache实际上缓存的是近期的热点数据，而Log分析完后可以删除，也就是说，不会用完存储空间

24：Facebook 2011：Batching IO，避免HBase hot keys？

    Java <--> Thrift <--> PHP

    Sharding plan：手工切分？这应该是没有数据中心之前的做法吧

    10000 writes per sec per server

25、Dropbox 2011：Python用于后端和client（python写的TortoiseHg/Mercury其实性能还不错，Sublime不也是Python写的嘛）；但是它不能用于Android（-_-）

    内存碎片问题

    PS：rsync同步大量的深度嵌套小文件时性能差，不如一次性压缩下载

26、Anti-spam（Mollom 2011）

    为保护ML算法，用户不能提交wrongly rejected的数据

    免费用户的输入可帮助改进训练ML

    disks -> SSD --> Cassandra：RAID 10（条带&镜像），for heavy writes & row caching；aging机制（正好可用于隐私，欧洲立法的“遗忘权”）

         可以设计用HTML5 Local Storage存储用户自己的全部本地数据~

    客户端LB：首先请求一个可用server list，然后顺序请求，一个不行换下一个（这里不能随便乱请求!）

    对IP地址的reputation机制？

    AWS虚拟服务器：IO是瓶颈，scale up

    16GB的coredump分析leaks？Oh crazy

27、Redis：LPUSH/LTRIM；LREM；ZADD/ZREVRANGE/ZRANK/ZRANGE；SADD；pub/sub；通常的get/set

28、可靠性：MTTR指标 <-- MTBF

   Capacity Planning & Expect Failure（k，独孤求败！）