goMars的学习随记

如何避免单线程模型的阻塞？Redis 实例有哪些阻塞点？和客户端交互时的阻塞点第一个阻塞点：集合全量查询和聚合操作。 键值对的增删改查操作是 Redis 和客户端交互的主要部分，也是 Redis 主线程执行的主要任务。所以，复杂度高的增删改查操作肯定会阻塞 Redis。 第二个阻塞点：集合元素的删除。 释放内存只是第一步，为了更加高效地管理内存空间，在应用程序释放内存时，操作系统需要把释放掉的内存块插入一个空闲内存块的链表，以便后续进行管理和再分配。如果一下子释放了大量内存，空闲内存块链表操作时间就会增加，相应地就会造成 Redis 主线程的阻塞。 第三个阻塞点：清空数据库。 既然频繁删除键值对都是潜在的阻塞点了，那么，在 Redis 的数据库级别操作中，清空数据库（例如 FLUSHDB 和 FLUSHALL 操作）必然也是一个潜在的阻塞风险，因为它涉及到删除和释放所有的键值对。 和磁盘交互时的阻塞点第四个阻塞点：AOF 日志同步写。 Redis 直接记录 AOF 日志时，会根据不同的写回策略对数据做落盘保存。如果有大量的写操作需要记录在 AOF 日志中，并同步写回的话，就会阻塞主线 ...

Redis实现消息队列概述消息队列在存取消息时，消息队列必须满足的三个需求： 消息保序 虽然消费者是异步处理消息，但是，消费者仍然需要按照生产者发送消息的顺序来处理消息，避免后发送的消息被先处理了。 重复消息处理 消费者从消息队列读取消息时，有时会因为网络堵塞而出现消息重传的情况。此时，消费者可能会收到多条重复的消息。对于重复的消息，消费者如果多次处理的话，就可能造成一个业务逻辑被多次执行，如果业务逻辑正好是要修改数据，那就会出现数据被多次修改的问题了。 消息可靠性保证 另外，消费者在处理消息的时候，还可能出现因为故障或宕机导致消息没有处理完成的情况。此时，消息队列需要能提供消息可靠性的保证，也就是说，当消费者重启后，可以重新读取消息再次进行处理，否则，就会出现消息漏处理的问题了。 redis实现方案List实现 消息保序 List 本身就是按先进先出的顺序对数据进行存取的，所以，如果使用 List 作为消息队列保存消息的话，就已经能满足消息保序的需求了。（即 LPUSH 和RPOP的结合） 为了即使没有新消息写入 List，消费者也要不停地调用 RPOP 命令，这就会导致消 ...

时间序列数据例如需要周期性地统计近万台设备的实时状态，包括设备 ID、压力、温度、湿度，以及对应的时间戳。 这些与发生时间相关的一组数据，就是时间序列数据。这些数据的特点是没有严格的关系模型，记录的信息可以表示成键和值的关系（例如，一个设备 ID 对应一条记录），所以，并不需要专门用关系型数据库（例如 MySQL）来保存。 基于 Hash 和 Sorted Set 保存时间序列数据 我们可以把时间戳作为 Hash 集合的 key，把记录的设备状态值作为 Hash 集合的 value。但是，Hash 类型有个短板：它并不支持对数据进行范围查询。 为了能同时支持按时间戳范围的查询，可以用 Sorted Set 来保存时间序列数据，因为它能够根据元素的权重分数来排序。我们可以把时间戳作为 Sorted Set 集合的元素分数，把时间点上记录的数据作为元素本身。 但是我们又会面临一个新的问题，也就是我们要解答的第二个问题：如何保证写入 Hash 和 Sorted Set 是一个原子性的操作呢？ 这里可以使用redis事务，当多个命令及其参数本身无误时，MULTI 和 EXEC 命令可以保 ...

集合类型常见的四种统计模式聚合统计概念：所谓的聚合统计，就是指统计多个集合元素的聚合结果，包括：统计多个集合的共有元素（交集统计）；把两个集合相比，统计其中一个集合独有的元素（差集统计）；统计多个集合的所有元素（并集统计）。 例子：统计手机 App 每天的新增用户数和第二天的留存用户数，正好对应了聚合统计。 要完成这个统计任务，我们可以用一个集合记录所有登录过 App 的用户 ID，同时，用另一个集合记录每一天登录过 App 的用户 ID。然后，再对这两个集合做聚合统计。 新增用户：两个集合求差集 留存用户：两个集合求交集 Set 的差集、并集和交集的计算复杂度较高，在数据量较大的情况下，如果直接执行这些计算，会导致 Redis 实例阻塞。所以，我给你分享一个小建议：你可以从主从集群中选择一个从库，让它专门负责聚合计算，或者是把数据读取到客户端，在客户端来完成聚合统计，这样就可以规避阻塞主库实例和其他从库实例的风险了。 排序统计概念：以在电商网站上提供最新评论列表的场景为例。 最新评论列表包含了所有评论中的最新留言，这就要求集合类型能对元素保序，也就是说，集合中的元素可以按序排 ...

RDB日志AOF日志记录了每条操作的命令，也正因为记录的是操作命令，而不是实际的数据，所以，用 AOF 方法进行故障恢复的时候，需要逐一把操作日志都执行一遍。也正是这个原因，RDB日志内存快照诞生了。 和 AOF 相比，RDB 记录的是某一时刻的数据，执行的是全量快照，并不是操作，所以，在做数据恢复时，我们可以直接把 RDB 文件读入内存，很快地完成恢复。 Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。 save：在主线程中执行，会导致阻塞； bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。 写时复制技术：利用写时复制技术，在执行快照的同时，正常处理写操作。 原理就是如果主线程需要对数据进行修改，则会复制一份副本对副本进行修改 小结AOF日志与RDB日志都有各自的优缺点，没办法做到完全完美。所以Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。 这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用 ...

AOF日志Redis 的持久化主要有两大机制，即 AOF（Append Only File）日志和 RDB 快照。AOF是写后日志，先执行命令再记录日志。这样就不会存在命令错误和阻塞当前写操作了。 风险： 如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。 AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。 写回磁盘策略： Always：同步写回：每个写命令执行完，立马同步地将日志写回磁盘； Everysec：每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘； No：操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。 AOF重写机制：AOF会随着命令越来越多而变大，这个时候就需要对AOF进行重写。重写机制具有“多变一”功能。旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。 和 AOF 日志由主线程写回不同，重写过程是由后台子进程 bgrewriteaof 来完成的，这也是为了避 ...

Redis的IO 模型Redis 采用了多路复用机制，使其在网络 IO 操作中能并发处理大量的客户端请求，实现高吞吐率。但是由于是单线程如果线程被阻塞了，就无法进行多路复用了。 多路复用的高性能 I/O 模型Redis是基于多路复用的高性能 I/O 模型，该机制允许内核中，同时存在多个监听套接字和已连接套接字（使用的非阻塞模式）。并且为了在请求到达时能通知到 Redis 线程，select/epoll 提供了基于事件的回调机制，即针对不同事件的发生，调用相应的处理函数。这些事件会被放进一个事件队列，Redis 单线程对该事件队列不断进行处理。这样一来，Redis 无需一直轮询是否有请求实际发生，这就可以避免造成 CPU 资源浪费。 Redis6.0新特性随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 IO 的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度。 单线程结构： 在之前Redis 一直被大家熟知的就是它的单线程架构，虽然有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF 重写），但是，从网络 IO 处理到实际的读 ...

用户权限创建用户 create user 'ua'@'%' identified by 'pa'; 这条语句的逻辑是创建一个用户’ua’@’%’，密码是pa。(%表示可以从任意ip登录，可以指定ip) 这条命令做了两个动作： 磁盘上，往mysql.user表里插入一行，由于没有指定权限，所以这行数据上所有表示权限的字段的值都是N； 内存里，往数组acl_users里插入一个acl_user对象，这个对象的access字段值为0。 权限操作 赋予权限：grant 权限列表 on 数据库.[.表名] to 用户名 [with grant option];(with grant option表示可以传递给其他用户) 取消权限：revoke 权限列表 on 数据库.[.表名] from 用户名; 全局权限： 全局权限，作用于整个 MySQL 实例用于管理MySQL服务器的操作，这些权限信息保存在 mysql 库的 user 表里，只能用*.*赋予。 revoke命令与grant命令，做了如下两个动作： 磁盘上，将mysql.user表 ...

快速的复制一张表mysqldump你可以使用下面的命令： mysqldump -h$host -P$port -u$user --add-locks --no-create-info --single-transaction --set-gtid-purged=OFF db1 t --where="a>900" --result-file=/client_tmp/t.sql 这条命令中，主要参数含义如下： –single-transaction的作用是，在导出数据的时候不需要对表db1.t加表锁，而是使用START TRANSACTION WITH CONSISTENT SNAPSHOT的方法； –add-locks设置为0，表示在输出的文件结果里，不增加” LOCK TABLES t WRITE;” ； –no-create-info的意思是，不需要导出表结构； –set-gtid-purged=off表示的是，不输出跟GTID相关的信息； –result-file指定了输出文件的路径，其中client表示生成的文件是在客户端机器上的。 再使用这个命令 ...

自增主键自增值存在哪？不同的引擎对于自增值的保存策略不同： MyISAM引擎的自增值保存在数据文件中。 InnoDB引擎的自增值，其实是保存在了内存里（重启重新去找自增值的最大值max(id)），到了MySQL 8.0版本后，才有了“自增值持久化”的能力（将自增值的变更记录在了redo log中，重启的时候依靠redo log恢复重启之前的值）。 自增值修改机制在MySQL里面，如果字段id被定义为AUTO_INCREMENT，在插入一行数据的时候，自增值的行为如下： 如果插入数据时id字段指定为0、null 或未指定值，那么就把这个表当前的 AUTO_INCREMENT值填到自增字段； 如果插入数据时id字段指定了具体的值，就直接使用语句里指定的值。 根据要插入的值和当前自增值的大小关系，自增值的变更结果也会有所不同。假设，某次要插入的值是X，当前的自增值是Y。 如果X<Y，那么这个表的自增值不变。 如果X≥Y，就需要把当前自增值修改为新的自增值。 其中，auto_increment_offset 和 auto_increment_increment是两个系统参数 ...