1. memcache@facebook
演讲者是Marc，FB资深架构师，对memcache应该是有很强的hands on经验，对各种细节逻辑了解清楚且反应迅速。这个talk讨论了FB对memcache的大量修改和扩展，使得memcache能够有效的scale并 承载极高的流量。
扩展的逻辑之复杂度个人感觉已经超过了原有的memcache。可以认为memcache是充分利用内存来开发可扩展高负载应用的一个良好基础。
Facebook的规模是400m活跃用户，每天billion级的status update，数万台服务器。
memcached服务器每秒承担400m gets请求和28m sets请求，cache了超过2T的items，超过200T bytes。
单台memcached服务器每秒承担80k gets和2k sets，receive 9.7M/s, transmit 19M/s。
Facebook的架构大致可以分为DB tier, memcached tier和Web tier三层。
为了memcache，FB实现了新的serialization库，比php serialization快速高效。
mcproxy: memcache tier的顶层是一组mcproxy服务器，用来dispatch请求。memcached服务器是有按照地域的水平分割和冗余的，mcproxy负责基 于这些逻辑进行分发。
对于Hot Keys（系统中出现的热点，比如名人的页面），复制到多台memcached。
对于同一来源并发的大量gets请求，使用Broad Shallow Multi gets的方法将其分组，可以减少gets请求数从而减少数据流量。相应的，memcached服务器要进行冗余和分组，使得每组gets请求只需要发到 一组服务器。
key missing和delete的情况都做了很多处理来scale。
展示了扩展后的key的状态机，看起来相当复杂。
Tesing的原则是test fast and don’t break things。没有使用test framework。
Why memcache works: easy, robust primitives, allow hacking.
2. Big Data in Real-time at Twitter
演讲者Nick Kallen。伯克利毕业，Twitter系统架构师，络腮胡，右耳有长耳钉，轻声慢语，气质相当文艺……
keynote在http://www.slideshare.net/nkallen/q-con-3770885。
Twitter的这个talk主要集中在大数据量和实时这两点上。加上下午的session，主要讨论了四个问题及其解决方法：
a) Tweets. 根据时间进行水平分割。利用查询主要集中在最近的分区这一Locality。但仍存在MySQL死锁，创建新分区费时费力的问题，计划中的解决方案包括基 于主键分区，Cassandra和memcached等。
b) Timeline. offline计算，预存结果。所有的timeline都是预存在memcache里面的，每条tweet都会offline的fanout到所有它应该 出现的timeline上。预存的timeline定期truncate以保证其大小在一定范围内。总结起来就是使用offline计算的原则是查询方式 固定且offline计算结果可以限定在一定范围内；另外一旦offline结果丢失，重建的成本也应该考虑在内。
c) Social graph. Information like who follows whom and who blocks whom. 解决方案简单的说是对每条边进行双向的存储，然后通过分区，冗余和索引来scale。具体比较复杂。
d) Search Index. 在Document的时间两个维度上进行分割。可能使用Lucene代替MySQL。
Twitter，FB以及其他很多talk里面都提到了Cassandra。根据了解到的信息，FB将Cassandra使用在Inbox等应用 上，而 Twitter认为Cassandra尚不能胜任critical的应用。