Reduce Data广告服务网站如何扩展到每天300K QPS请求？分享经验如下：
1. 为大规模设计，广告服务平台从一开始增长就很惊人，因此，系统开始就为大规模设计，系统为水平和垂直伸缩扩展。
2.选择CAP定理中的AP（可用性和分区容错性）二不是CA（一致性和可用性），因为广告拍卖与服务平台是追求低延迟和高性能，数据的高一致性不是非常关键。
3.没有锁定专门厂商软件或专利技术的限制使用，积极使用开源软件，开源软件已经达到非常成熟的程度。
4.基于Mechanical Sympathy（顺硬件之势而为）构建系统，一个软件的建立应该是基于理解硬件如何工作以及如何更好利用硬件。
5.云技术的限制使用，他们很早就决定对云技术的有限使用，因为a)EC2和计数部分往往非常昂贵；b)在对EC2早期的测试中发现网络抖动jitter、磁盘虚拟化等会增加延迟。
6. 延迟总是存在，对付它而不是设法消除它。所有查找都应该发生在1ms以下。 利用RocksDB和各种其他解决方案作为主要的缓存/嵌入式数据库。
7.使用SSD固态硬盘降低延迟
8.没有虚拟化硬件，充分利用高配置硬件(256G内存和24核机器)并行化许多计算。
9.磁盘写操作，每N秒定时flush写入大块数据
10.Nginx用于支持keep-alive连接，而Netty优化支持大型并发负载。
11.为了保证广告服务器中关键数据始终是立即可用(访问延迟以微秒计)，所有这些数据都是存储内存中库/数据结构中。
12.架构应该使用share nothing，当我们增减服务器时，系统应该是丝毫不受影响，眼睛都不会眨一下。
13.所有关键数据 结果都需要复制。
14.保持每天的原始记录日志拷贝
15.如果数据有点脏，系统发生数据不一致性，这一切也是正常
16.消息系统应该是容错的，它们可以崩溃但是不会丢失数据。
下面是具体设施情况：
跨3个数据中心的40–50节点(primarily US and two nodes in Germany)
其中30台运行高计算 (128–256G RAM, 24 cores, top of the line CPUS and where possible SSDs)
其余机器配置低一些， 32G RAM, Quadcore 机器.
10G 私有网 + 10G 公网
小型 Cassandra, Hbase 和 Spark 集群.
使用关键技术是：
1.HBase 和 Cassandra 用于计数聚合，以及管理用户和账号数据集， Hbase 因为其高性能写操作，能够很好处理计数器，并提供近实时的分析。
2.后端主要语言是 Java. 尽管有C++ 和 Erlang经验，但是Java有更可用的成熟技巧以及过去几年JVM相当成熟。
3.使用Google Protobuf进行数据传输
4. Netty作为主要后端服务器，感谢其简单和高性能特点。
5.RocksDB作为用户配置读写， 它是一个嵌入在每个广告出价人中的嵌入式数据库，用户配置通过Apache Kafka跨RocksDB同步数据。
6. Kafka作为主要的消息队列，流化数据处理。
7.CQEngine作为主要的基于内存 快速查询系统，使用原子对象存储数据。
8. Nginx作为主要的反向代理.
9. Apache Spark用于为ML机器学习处理而需要的快速数据处理。
10.Jenkins 用户CI持续集成
11. Nagios 和 Newrelic用于监视服务器。
12. Zookeeper用于分布式同步。
13. Dozens of third parties for audience segments, etc.
14. Bittorrent Sync用于跨节点和数据中心同步关键数据。
15. 基于雅虎白皮书的预算控制定制的配额管理。
最后，他们在提高改进部分提到了引入LMax的Disruptor框架进行预先聚合，提高跨RocksDB数据的内部复制方式。
How we scaled: 300K QPS & 3-5B requests a day — Me