分布式原理：Cassandra
这是一个分布式存储的框架，或者说，直接就是一个分布式的数据库解决方案。
它可以让任意一个用户访问到data center并作增删改查
假设让你设计一个分布式的数据库，你会怎么设计？
首先，这个数据中心的架构得是按照一致性哈希来搞的哈希环，这样才能保证新增节点的可用性。
https://zhuanlan.zhihu.com/p/457125100
那么怎么设计partitioner呢，在chord协议里，我们用了finger table来引导你找到资源的位置，但是那样太复杂了，我们直接把所有信息都写在node server里就行，这是一种工程里常用的方法，虽然不是最优的，但是效率最高。
然后我们又要考虑了，作为一个稳定的分布式数据库，你肯定不能一份资源就放在一个地方吧！如果在的那个node挂了，你的资源就无了。所以我们要做很多的副本（replicas）。
如何放置这些副本呢？有几种可行的方法：
- 随机放，算hash 然后mod
- 按照信息来放，比如放用户信息，按照用户名的首字母a-z分别放
为了可拓展性，我们直接定义一个服务器就只用来放replicas，就叫它Snitches（告密者），因为它看到了信息，还自己复制了一份放在别的地方，就很像告密的人。
- A snitch maps IPs to data centers and racks
然后如何读写呢?
写：
**先来看看客户端：**我希望我访问哈希环上任何一个节点，都能拿到我想要的资源，就很像，你去任何一个移动联通营业厅，都能办成业务。那么我就定义我去的这个节点叫营业厅（Coordinator），它负责跟其他的节点进行交互，我只需要它交互完告诉我最后我要的东西就行。
那么营业厅干了什么呢？
先通过partitioner给有你想要资源副本的node发消息（query），然后得到信息返回给用户（client）。
我们再来看看服务器，snitches会告诉许多node许多replicas，所以当node收到之后，首先会在commit log里面写上有关这条信息的log，然后再memtable（内存里的table）里加上资源。
然后你就要问了，memtable断电不就无了吗，欸，这就是为什么要写commit log！
那你又问了，那一直在内存里写东西是不是不合适！是不合适，所以，当memtable满了或者时间太长了之后，会把它flush进SSTable，SSTable就是一个kv型的表了。
因为SSTable再快也是硬盘，如果东西多了找key也是很慢的，所以需要一个方法快速找到这个SSTable里有没有这个key：
就用了一个比较常见的方法**（Bloom filters）：**
就是经常用的 布隆过滤器！
首先在insert的时候，定义K个哈希函数，分别给key进行处理，比如最后K个哈希函数的结果分别是2，5，1，34，435，66445。然后找一个bit表，把这些位置上的bit从0变成1.
在查找的时候，同样用k个哈希函数对key处理，然后看看相应bit表上的值是否是1，如果有0就说明不在表里。
这里有一个疑问：感觉好像是没有问题的，但是会不会出错
有两种错误情况：
1.表里有的，但是检测出来没有： false negative
不可能出现，因为这个bit table的性质，insert过的一定能查出来
2.表里没有的，检测出来有：false positive
这个是有可能出现的，比如两个数的两个不同哈希函数的值碰巧一样。但是这个可以忍受，毕竟不是十全十美的。
改：
客户端其实是一样的，就客户跟营业厅说一下要改
然后到了服务器这边，服务器不会立刻修改，而是给新数值插入，并标一个timestamp，删除也是一样，它会给那个资源标一个tombstone。
之后会执行一个叫做Compaction的操作，它会遍历所有node里SSTable里的文件，把timestamp最晚的留下来，然后把有tombstone的文件删掉
读：
最后来说一下读，读也是很简单，营业厅帮你读所有node的replicas，然后找到timestamp最晚的那个。
成员表：
主要也是用gossip的方法来传递成员信息，也引入了怀疑机制。