分布式

为了将写路径扩展到最终用户，我们需要从根本上重新思考构建这些系统的方式：从**请求/响应交互交互**转向发**布/订阅数据流**！

共识问题是分布式计算中最重要也是最基本的问题之一，表面上看，只是让几个节点就某件事情达成一致。这似乎很简单，但是许多失败的系统正是由于低估了这个问题所导致的。 在探讨了复制、事务、系统模型、线性化和全

投入大量资源，也是可以达到非常高的时钟精度。比如金融机构要求**高频交易基金**必须在UTC **100微妙**内同步时钟，以便调试‘崩盘’等市场异常并**检测市场操纵**等违规行为。 高精度的时钟

批处理容错方法要确保批处理作业的输出和没有出错时的最终结果相同，即使中间某些情况失败了，看起来好像每个输入记录都恰好被记录了一次，没有记录被遗漏，也没有记录被处理两次。 这个被称为**恰好一次**语

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第10天，点击查看活动详情 本系列主要是《数据密集型应用系统设计》阅读笔记，本文记录流处理主题的笔记心得。 流式join 通过主键来

因此，在消息处理的代价很高，希望并行处理，而且消息排序又不那么重要的情况下，AMQP和JMS风格的消息代理更可取。另一方面，**在消息吞吐量高的情况下，每个消息处理速度快，消息顺序又很重要的情况下，基

解决并发问题的直接有效方法是避免并发。 多线程并发在过去30年的时间一直被认为是提升性能的关键。那么现在也有逐渐转向单线程执行的趋势，是为什么呢？ - 内存越来越便宜 - OLTP事务通常非常快。而运

迁移之后，至少满足： - 负载、数据、请求等更均匀的分布 - 再平衡的过程中，数据库应该可以继续提供读写服务 - 避免不必要的负载迁移，以加快动态再平衡，尽量减少网络和磁盘I/O影响。

对于医生值班的例子，我们可以使用`for update`加锁步骤1的结果来保证事务安全。但是对于会议室预定系统这个场景则不适合，因为`for update`无从加锁。串行化的隔离的能解决这个问题，如果

**如果所有的读写都是同一个关键字，则最终所有请求都被路由到同一个分区**。 比如社交媒体上，一些名人用户有数百万的粉丝，当发布一些热点事件时可能会引发**访问风暴**。此时关键字是名人的ID，哈希起

对于又**要异步同步副本**，**又要从副本读取数据**，在应用层可以提供比底层数据库更强有力的保证，例如只在主节点上进行特定类型的读取。代价是，应用层代码中处理这些问题通常会非常复杂，且容易出错。

本文本文探讨的范围是索引中的普通索引，分析了Mysql索引的一些问题，主要是关于怎么建立索引、索引的存储结构以及思考关于怎么命中索引的问题。 是否了解到了？ - 经常使用和联查的列要加索引 - B+

普通索引a通过B+树查找匹配的a值，获得一个集合Collection(r1,r2,r3,...)，其实r1是DB内部创建的**row_id** - 假设a索引的每个a值平均有100行记录

本文多图详解，旨在一通百通分布式关键思想。 初始化的过程需要设置种子节点，各个节点根据能力生成X个随机数，通过gossip协议获得全局的哈希地图。 之后各自负责数据分片，来处理数据请求并存储复制

日志状态机：系统有完全一样的数据（1，2，3，4，5，6，7），但是通过term的表示可知道系统演化的状态是有区别的。（**index=2，term=1**）和（**index=2，term=2*

首先查询语义不一致，其次，statement格式的 binlog日志和数据不一致，这会导致主备不一致。 所以next-key锁可以保证即使是在statement格式，binlog日志和数据也是一致的