数据库相关
索引的处理：
- 内存映射文件
MongoDB, Cassandra, Riak等
- 较小的索引集合，采用元索引或者bloom Filter进行一些优化
一旦内存数据足够多，比如达到MB，我们就对它们进行排序，而后将它们作为单个小的索引写入硬盘中。最后得到的是一个小的、由不变索引文件组成的年表。
- 简单匹配算法（brute force）又叫做面向列（Column Oriented）
日志结构合并树，在HBase,Cassandra等不同地方应用。
将索引存储在内存中，或者利用诸如日志结构合并树(Log Structured Merge Tree)这样的写优化索引结构，绕开“随机写惩罚”(random-write penalty)。这是第三种方案为纯粹的简单匹配算法(Pure brute force)。
面向列是一种简单的理念，和行存储数据不同，通过列分割每一行，将数据追加到单个文件末尾。接着在每个单独的文件中存储每一列，一旦需要只需读取需要的列。
这样可以确保文件的含有相同的序列，即每个列文件的第N行含有相同的地址或者偏移量。这个很重要，在某一时刻读取多列，来服务一个单一的查询。意味着“连接(joining)”列速度飞快，倘若所有的列含有相同的序列，我们就能在一个紧凑的循环中这么做，此循环有很好缓存和CPU利用率。许多实现大量使用向量( vectorisation)进一步优化简单连接和过滤操作吞吐量。
诸如卡夫卡(Kafka)采用一个简单的、基于硬件的高效消息规范。消息可以简单地追加到文件的末尾，或者从预定的偏移量处读取。可以从某个偏移量读取消息，来来回回，你可以从上次结束的偏移量处读取。看得出是很不错的有序输入输出(IO)。
这和多数面向消息的中间件不同，JMS(Java消息服务)和AMQP(高级消息队列协议)说明文档需要额外的索引，来管理选择器和会话消息。这意味着它们结束某个行为的方式更像数据库，而非某个文件。著名的论述是1995年Jim Gray发表的队列就是数据库(Queue’s are Databases).
分布式数据库下的CAP（Consistency, Availability, Partition-Tolerance）
前端读服务
是不是借鉴机器人？
一些设计原则
- 无状态
- 数据闭环
Hash Tag - 缓存银弹
- 并发化
- 降级开关
- 开关集中化管理：通过推送机制把开关推送到各个应用；
- 可降级的多级读服务：比如只读本地缓存、只读分布式缓存、或者只读一个默认的降级数据；
- 开关前置化：如架构是nginx—>tomcat，可以将开关前置到nginx接入层，在nginx层做开关，请求不打到后端应用。
- 限流
- 切流量
- 其他
1、首先接入层读取本地proxy cache / local cache；
2、如果不命中，会读取分布式redis集群；
3、如果还不命中，会回源到tomcat，然后读取堆内cache；如果没有，则直接调用依赖业务获取数据；然后异步化写到redis集群；