strive for the best 的博客

我们在之前数据库的基础篇大致谈过一些事务的隔离级别的内容具体见添加链接描述为什么事务要隔离ACID四大特性分别是，atomicity原子性.consistency一致性，isolation隔离性以及durability持久性。这里为什么需要隔离性，因为在实际工程当中，经常会出现一些问题，这些问题大致是：脏读不可重复读幻读为了解决上述问题，因此强调隔离性。事务的四种隔离级别读未提交：某事务还未commit，他的改变就能被别的事务看到。这种情况会出现上述三种问题。对锁的要求很低，即读不需.

在分布式环境中，我们倾向于比较均衡的利用每台机器，不至于单点过载，也能发挥集群的最大价值。比较常见的方法是轮询与随机分配，一般按照实例多少加以权值，所以一般采用的是加权轮询以及加权随机。但是大多数策略问题在于：无法应对带有多种状态的请求或者服务有状态的请求：我们再分布式KV缓存系统中，往往会把数据水平切分到不同节点来存储，为了保证系统可用性，冗余是必要的，对于这样的系统，某个key值应该在某一个确定的节点上获取，而不是随便访问一个节点都能得到全局的key 这样的服务我们认为是有状态的。再比如，dag中某

UUID——全局唯一ID——universally unique identifie。一般来说常用的基于时间进行排序，因为时间是自然递增的。但是全局唯一ID的两个核心要求是：在分布式环境下，很有可能多台机器同时产生了同一个ID，这样就无法唯一的标识某项业务。我们可以独立部署一个服务，专门用于生成ID。其他需要ID的服务，都调用这一个接口，这样在一台机器上我们就可以利用本地的时钟或者计数器来分发ID。问题一：时钟回拨计算机底层的时钟，主要依靠石英钟，本身是有一定的误差的，计算机定期请求NTP服务，来同步当前

先搞清楚分布式一致性到底解决的是什么问题我们知道数据库中 redo log经常用以记录数据变更，数据在被日志记录之后才会被应用。如果多个节点存储的是同样的东西，我们怎么保证在经过一番更改之后，这些内容还是一致的呢？客户端通常只会向分布式系统中的某个服务器发起请求，然后由这个服务器的一致性模块，在多个复制状态机之间进行消息的同步，正常情况下，多个节点同步都会成功，这样不同节点的日志自然也都是一致的，所有的节点都会以相同的顺序包含相同的请求，从外界看起来，行为也就像是一台机器一样。但是如果服务器发生了故障，

在大量的数据处理需求下，程序是分布式运行的，但是每个业务如果都需要针对雷同的问题各自做出雷同的处理，效率太低。例子假设一个 number 数组中，我们希望统计出数值大于 5 的那些数向上取整的和。这个问题很简单，常规的写法自然是遍历整个数组，写一个 if-else 判断出大于 5 的数，然后用一个变量做累计求和。但是这个写法引入了状态，在循环里你既需要关心 filter 的逻辑，又要关心累计求和的逻辑，不够清晰。但是如果这样写：通过三个原语区分开控制逻辑和计算逻辑。如果我们把输入数据表示成一个键值对K

谷歌三驾马车——mapreduce,page rank,google file system。PageRank 算法不止可以让用户搜索到自己关心的内容，也往往能让质量更高的网页得以排到更前的位置，同时它也是一个典型的 MapReduce 的应用场景。思想源于学术论文的引用次数，高引用的文章一般来说被认为是质量高的文章。被更多超链接指向的网页，可以推断它往往会有更好的质量，因为当时许多 HomePage 类的导航网站都会链接到一些提供优质服务的网站，如果一个网站质量很差，自然也不会被太多链接所指向。但不同网页

Kafka 是一款性能强大且相当常用的分布式消息队列，常常用于对流量进行消峰、解耦系统和异步处理部分逻辑以提高性能的场景。在kafka中，所有的消息都以日志的形式存储。这种日志只允许追加新数据，不允许修改之前文件内容日志文件的存储方式：每个topic有多个partition，每个patition有多个有序日志段即如何为日志文件建立一个索引，这里很关键的一个问题在于offset是自然线性增长的，是有序的我们来看一个topic中一个patition的日志文件格式：我理解前面属于相较于物理第一个文件的绝对偏

最简单的暴力方法大家应该都会写，我们来看一下优化。最主要的问题在于，能不呢利用之前已经匹配的一部分，进行继续匹配，而不是从头开始基于预处理来避免不必要的重复。从模式串的末尾，往前匹配坏字符的作用是跳过一些肯定不可能成立的匹配位置，描述的是主串上的失配字符。当我们对其s和p之后，从p的末尾即p[6]开始匹配。发现和s[6]不一致，此时s中不匹配的s[6]=S，就是坏字符发现坏字符之后。检查模式串p中是否有S，没有，直接从S[7]开始匹配因为没有就说明了，模式串中任何一个部分都不可能与目前的s重叠，跳过

内存是有限的，而所谓外部排序的这个外：指的是外部存储。已知1GB的内存如果要处理1TB，至少要读1024次。所以大体思路一定是：将文件分段，用常见内部排序方法进行排序完了之后，再合并。即思路上大体是归并排序1.内部排序我们分成一段一段之后，主要目的是使得内存能够装下这一段数据。一般来说，快速排序在大部分场景下都是最快的2.归并阶段因为需要归并n多个段，此时的内存肯定无法装下超过一个段的内容。此时最大的时间消耗来自IO。内存的读写操作是很快的，但是外部磁盘中读写，可能比内...

前提回顾我们在这一篇添加链接描述里也大致介绍过双端队列这种数据结构。回顾一下，大致是说有一个指针数组，里面每个指针指向一段连续的空间。这样只需要在头部和尾部放两个指针即可执行双向的操作。而后遍历指针所指的连续空间时，需要四个指针，两个指向头尾，一个指向正在遍历，第四个则指向当前连续空间在指针数组中所存放的位置。补充因为主要原理在之前的博客中基本已经介绍过了，这里只做一些补充。首先明确deque和普通的queue共同点在于：语义上来说并不支持数组基于下标在指定位置的修改、插入和删除的操作。

单链表我们日常接触最多的就是单链表。其优点很明显，增删改很方便。但非连续存储的方式，导致了我们随机访问第i个元素的时候必须从头遍历，时间复杂度为O(N)所以单链表比较合适于以下频繁的场景：插入/删除遍历但不适用于随机访问频繁的场景。list的实现——基于双向循环链表这个我们之前也提及过：添加链接描述我们之前说list列表基于双向链表实现，但没说细节，我们首先来看一下node的情况：既然是双向链表，很明显会有前后两个指针和一个val值。template <class T&g

开新专栏啦，该系列是 极客时间-黄清昊-算法实战高手课 的学习笔记，以此为媒介深挖我们之前提到但没展开的内容。希望大家一起学习，一起进步。回顾我们在之前的内容，分享过vector作为顺序容器的一部分内容：c++stl我把之前的内容挪一部分来：动态数组，用于 O(1) 的随机读取.实现原理：由三个指针实现，第一个指针指向vector起始位置第二个指针指向目前有数据的末尾第三个指针指向整个vector容器所占内存的末尾。由此实现：template<class _Ty, .