iUcool的博客

在分布式系统中，延迟队列是一种常见的需求，例如订单超时取消、任务定时执行等。Redis 作为高性能的内存数据库，提供了多种实现延迟队列的方案。本文将介绍几种不同的 Redis 方案，并分析其优缺点及适用场景。

当我们需要统计实验中每个分支的实际进入次数时，如何设计一个高效、可靠且对业务影响最小的方案，成为了关键。以下是几种常见的流量统计方案的分析与实现设计目标。

对于一金额字段，由于会高频更新字段金额（一秒上百次），该如何设计技术方案处理可能出现的性能、一致性问题呢？

以 TF - IDF 为例，如果文档中某个词出现的频率高（词频高），但在整个语料库（索引中的所有文档集合）中该词比较少见（逆文档频率高），那么这个词所在的文档相关性得分就会相对较高。例如，在一个美食相关的索引中，如果 “全聚德烤鸭” 这个词在某篇介绍全聚德的文档中多次出现，而在其他文档中很少出现，那这篇文档在以 “烤鸭” 为查询词时相关性得分就会比较高。是一个不变的、独立的倒排索引，储存了文档的字段、倒排表、储存字段以及其他索引元数据。分片会从它的所有 Segment 中收集匹配的文档，并按相关性排序。

此外在哨兵故障检测之外还存有节点自检，目的在于确保节点间通信正常，维护集群状态。以保证其他主节点知晓该主节点已经下线，并且防止从节点同时启动选举。如果手动配置新主节点或者槽迁移恰好碰上了故障选举，使得同一选举期存在多个主节点，那么该如何处理冲突呢？从节点会计算选举期，若获取的票不在本轮选举中，则不会进行计数。NodeID字典序更小的节点将成为唯一的主节点，并递增选举期。若故障节点为主节点，集群尝试从主节点的从节点中选取新主节点。会不会存在一个从节点收到了同主节点的两轮选举的投票呢？主节点在投票一次后，在。

在本地测试中我发现了一件令我惊讶的事情，在300w数据量对json字段里面值进行筛选的时间都在100ms左右！那么为什么mysql json查询这么快呢？

在很少会有中间插入或者对查询排序有较高要求的情况：较短间隔的int是更优的方法在中间插入情况较多的时候：可能float类型更为合适链表方法在插入情况较多的时候也是非常适用的，可是查询性能属实太差数据量少：可以用配置文件或者直接在缓存中设置排序。

VLL锁管理结构由储存到每个原始数据的的未完成锁写请求数量CX和未完成锁读请求数量CS中心事务请求全局队列TxnQueue组成。

我们知道varchar类型的列最多允许65535字节，在允许NULL的情况下最多储存65532字节，因为NULL标识符占1字节，真实长度数量占2字节。此外，65532这个限制是所有varchar列的长度总和，也就是如果存在多个varchar字段，虽然单个没有超出限制，但这多个字段如果合起来超出了限制，那还是会无法创建的。之所以是记录到下条真实数据的偏移量，而不是下条数据偏移量的原因在于可以利用局部性将前面数据的逆序储存的字段长度、NULL值列表缓存起来，减少数据再次查询硬盘次数。

考虑到redis主从同步集群中，如果从master获取到锁之后，就故障换成了从节点，那么就会导致锁失效，因此提出了RedLock的分布式锁算法。该算法依赖于这样的假设:虽然进程之间没有同步时钟，但每个进程中的本地时间几乎以相同的速率更新，与锁的自动释放时间相比，误差很小。在上述锁中，存在一个问题——如果A获取了锁，但是由于执行时间过长，导致B也获取到过期后的锁，此时并会同时存在多方获取锁。以下是删除特定value的锁的lua脚本，这样就可以防止删除不属于自己的锁。在锁竞争比较激烈情况下，性能损耗较大。

在发布订阅中我们了解到发布订阅模式存在的无法持久化保存消息和对于离线重连的客户端不能读取历史消息的缺陷，以下就来了解一下stream是如何解决这个问题的steam是类似于仅添加log的数据结构，提供了以下基本命令XADD: 添加新条目到streamXREAD: 读取条目XDEL: 根据id删除消息DEL: 删除streamdel skeyXRANGE: 返回范围内的条目XLEN: 返回流的长度xlen skeyXINFO: 展示stream的信息。

而基于模式的订阅是通过pubsub_patterns的链表去实现的。订阅时创建包含客户端信息和模式的pubsub_patterns，并添加到链表中。发布订阅的实现其实是通过key为频道value为储存订阅频道客户端的字典的链表去实现的，发布时直接遍历所在频道的链表进行消息发送。在发布时，就会遍历该链表检查是否匹配模式，然后发送消息给匹配客户端。

若一组任务堆积量太大，或者堆积时间太长，则让其他工作节点每处理完一批本组数据，便要处理该堆积数据，直到该堆积数据低于阈值量或者阈值时间。设置一个批次插入为一个任务，在此定每次插入1000条数据，那么每个文件总共就是1w个任务，这1w个任务便为一个任务组。工作节点收到数据后，连接数据库，根据负载情况开启多线程对所接收任务，以任务ID组合行数作为表id进行插入数据。工作节点完成本节点绑定的所有任务之后，便可以开始抢占其他节点任务，以未完成量最多的任务组为优先。超过该任务数，进行抢占其他任务组或者等待。

更好的办法，已知期望配送日期一定不早于下单日期，那么只要用户的首单日期与最小的期望配送日期相等，那么这个首单就是即时订单。那么只需要对count()、sum()做些小小改变，count()会忽略null，那么如果都是null，返回值也就是0了；sum()如果都是null，才会返回null，那么只要在无值的时候返回0就可以了。我最初的方案原本如下，就是根据国家区域和月份分组聚合，但是忽略了在没有匹配数据的情况下sum()、count()会返回null。此外也可以根据month、group分组。

为了解决这点我们可以用上聚合函数min()去做到，如果不用的话，将会导致取到顺序的第一个登陆日期，而不是我们期待的第一次登陆日期，本题关键在于如何判断数字是连续出现的，诀窍在于采用三表连接，表a、b、c的id分别是连续的，并且num相等。两个条件就是两个子查询，我们只需要在子查询中找到所有满足条件的数据就可以了。与方法1思想类似，也是统计大于等于分数的个数，只不过是采用同表连接。在本题中，如何在group中取第一次登陆日期将是难点所在。以大于本分数的数量作为rank。如何输出相应的rank？

超过经理收入的员工显然是要将同一张表，作为经理和员工表连接。这里存在两种方法，一种是采用WHERE。居然不能select后update，还要通过一个中间表去解决。本题的关键在于多表连接，三表之间的连接与两表是一致的。对于前者直接采用distinct关键字，而后者可以。本题的关键点在于过滤掉重复的以及null的处理。最先想到的方法是找到所有订购过的，然后排除。另一种巧妙的方法是左连接筛选。另一种是使用JOIN。

嵌套集合模型是根据遍历树对节点进行编号，遍历树对每个节点进行两次访问，按访问的顺序分配编号，并且在两次访问时都进行编号。更新需要重新编号，因此代价很高。比如对于下表中的mac air m2是第3步时发生了第一次访问，同时由于是最左子节点，因此会发生返回，那么第4步发生了第二次访问。对于查询就相对比较麻烦了，需要通过like之类的，并且完整路径很有可能会超出索引的最佳长度，对查询性能有损耗。nested set方法查询删除所有子节点非常快，然而模型较为复杂，插入移动极为麻烦，需要重建left、right。

其实从left join的原义也可以知道，会保留join时左表的所有项，那么就不应该在join的时候将左表数据筛选掉。而右表本来是能够筛选的。一般情况我们可能只在join on 后面添加唯一的关联条件，但是如果在on后面添加多个条件会发生什么呢？但是对于left join，情况就比较微妙了。表现与在where后面添加条件一致。对于inner join。

从历史来讲binlog先于redo log，在以前innodb还不是mysql默认引擎的时候，mysql server层便已经采用binlog记录了所有数据表结构变更和表数据修改的日志。从使用用途来讲，binlog采用的是追加写，不会覆盖原来的日志，这很适合进行数据恢复或者主从复制，而redo log由于是循环写，因此无法进行整体的恢复或者复制。在记录需要修改的时候，先更新buffer pool，然后将修改通过redo log记录下来，最好会在适当的时候将buffer pool刷新到硬盘。

buffer pool是主存中的一个区域，InnoDB 在访问时缓存表和索引数据。缓冲池允许直接从内存访问频繁使用的数据，这加快了处理速度。在专用服务器上，高达80% 的物理内存通常分配给缓冲池。为了提高大容量读取操作的效率，将缓冲池划分为可能包含多行的页。为了提高缓存管理的效率，缓冲池被实现为页链表;使用最近使用次数最少(LRU)算法的一个变体，很少使用的数据被老化到缓存之外。

通常我们说redis是单线程指的是从接收客户端请求->解析请求->读写->响应客户端这整个过程是由一个线程来完成的。这并不意味着redis在任何场景、任何版本下都只有一个线程。

redis rehash利用了和golang类似的方式，将真正的rehash操作放置到了dict增删改除中，有效地分摊了rehash性能消耗。不同之处在于更进一步作为一个数据库应用产品利用了闲暇时间去进行rehash。为有效利用宝贵内存空间，添加了缩容，还添加可以在较高的使用率下的内存回收扩容前预估是否超出内存限制出于对响应时间的敏感性，redis还设置了最大空桶访问次数redis没有考虑到桶overflow太多的情况。

mysql select执行流程如图所示。

不过如果后更新的失败了，那么先更新数据库的情况会是更优的选择。因为只是缓存出现不一致，但是相应的操作逻辑与数据库数据保持了一致，并且缓存可以通过消息队列进行重试或者是订阅mysql binlog同步数据。不过这种情况发生的概率不高，需要读线程读缓存恰好失效，写线程速度快于读线程。另外一种方法则是不更新缓存而是删除缓存，而删除缓存也分为两种情况。如果采用先删除缓存，那么在考虑查询重建缓存的情况下，比如。此时数据库x值为x，缓存值为1，还是会出现不一致的情况。先更新数据库在高并发的情况下，可能会出现。

分布式事务是为了保证不同数据库数据一致性。

如果希望更快地恢复数据，希望最大化Redis性能，那么RDB更佳。如果希望更高的安全性，那么AOF更适合当然也可以全都要。

ACID是数据库事务的四个关键特征。

总的来说ziplist就是在建立储存数据较小的情况下疯狂压缩元信息的储存空间，比如对于一个用一个byte能够表达的数据长度，就不会占用整个int的长度，当然坏处就是如果长度超过了一个byte能表达的，那么相比于直接用int的方式其实是会更加占用内存并且这种压缩方式是建立在连续的内存空间中（猜测应该是为了节省指针带来的多余内存占用），那么一旦出现重新分配内存的情况，那么可能会引发连续的内存分配，那么这个性能就会相当差。

在我看来本论文的主要贡献在于相对减轻了传统LSM compact所带来的写放大问题。其核心设计在于使key、value分离以及gc只保持有效数据。

MVCC是一个常用于数据库管理系统的并发控制方法，能提供对数据库的并发访问在没有并发控制的情况下，如果有人在读取数据的同时，另外有人在修改数据。那么读者可能看到一段写一半或者不一致数据。MVCC则旨在通过保留数据项的多个副本来解决问题。当MVCC数据库需要更新数据时，不会用新数据覆盖原数据，而是创建该数据的新版本。每个事务看到的版本取决于隔离级别。常见一个例子就是修改博客后常常需要审核，在审核通过之前，会将未修改过的旧版本给读者看，当通过之后就给最新版本看。

Mysql常用引擎InnoDB支持行锁、表锁，而MyISAM则不支持以下均默认InnoDB以下是MySql锁类型共享排他锁从是否共享来看可以将锁分为共享、排他锁。不同事务可以对同一行记录加共享锁若一事务对某一行加共享锁，其他事务请求排他锁不能被立即允许若一事务对某一行加排他锁，那么其他事务就不能加共享或者排他锁，从而导致锁等待可以总结共享、排他锁兼容关系如下图所示InnoDB中，只能给索引上的索引项加锁来实现，也就是说对于非索引项加锁，将会使用表锁。意向另一种为了让行级.

事务是通过要么都执行要么都不执行的特性来实现原子性。在Spring中主要通过@Transactional注解来使用事务，实际实现是通过AOP实现以及需要数据库的支持。在spring中事务主要通过以下3个进行管理PlatformTransactionManager：平台事务管理器TransactionDefinition：事务定义信息（事务隔离级别、传播行为、超时、只读、回滚规则）TransactionStatus：事务运行状态，比如是否新事务、是否可以回滚Spring为所有平台都提供了接口P