m0_57015193的博客

redis 常用的数据结构有以下五种：- String- List- Hash- Set- Sorted Set之前简单的介绍了 String 实现原理 SDS，本篇我打算从全局层面一起介绍：无论什么类型的数据结构，在 Redis 中都可以通过 RedisObject 来表示，该类型主要包含以下三个属性：- type：类型，对应上面提到五种数据类型，如：REDIS_STRING、REDIS_LIST 等等- encoding：编码格式- ptr：指针，指向具体的数据类型Red

本篇我打算简单整理一下关于 MySQL 分库分表的基础知识分库：将单个数据库拆分成多个数据库的过程分表：将单张表拆分为多张表的过程总得来说分库分表的原因主要有以下几种：提高性能，增加并发量，增加安全性提高性能是说单张表数据量太大时，数据库查询效率变低，通过拆分数据的方式提高查询性能增加并发量是说单个 MySQL 实例最多支持 2000 左右的并发量，一般超过 1000 数据库就已经很危险了，所以可以通过拆分多几个 MySQL 实例，通过分流的方式减少单个实例上的压力，防止高并发流量直接将数据库

红黑树是二插平衡树的再优化，二插平衡树强制要求左右子树高度差不能超过1，并且它的左右子树也得是二插平衡树。这就导致每次添加、删除元素时需要大量的操作保持树的平衡，红黑树在其基础上优化，它不强制要求高度差必须小于1，但也尽可能保证树相对平衡，查询效率也高首先红黑树需要满足以下几条规则：1. 节点非黑即红2. 根节点必须黑色3. 每个叶节点（不是叶子节点，页节点值 NIL 或空节点）必须是黑色4. 每个红色节点的两个子节点必须是黑色5. 从任一节点到每个叶节点所经过的黑色节点数目相同也就是说

上篇博客我简答介绍了 redis 常见加解锁的操作，本篇我计划整理出其中可能导致的问题：一般情况下 redis 分布式锁都是这样使用的：// 加锁操作cacheService.lock(key , timeout);// 业务逻辑xxx// 解锁操作cacheService.unlock();绝大多数情况下都没有问题，但可能存在如下情况：业务逻辑执行时间过长，锁自动失效了。如果锁失效，就有可能导致并发问题一般情况下都是通过设置 timeout 值大于业务逻辑执行时间来解决，但总得来说这不

线程池可以帮助我们省去创建、回收线程所带来的资源消耗，这也是目前使用线程池的主要原因：下面我根据线上业务依次分析常见的几种线程池并给出个人理解：SingleThreadPool：无界队列，核心线程、最大线程都为 1特点：只有一个线程，阻塞队列使用 LinkedBlockingQueue，链表无界。优点在于保证顺序我个人不推荐使用这种线程池，首先它的应用场景很少，单个线程也无法发挥多核的优势。只适合用于一些边缘业务，不重要也不考虑稳定性的场景可以通过这个线程池慢慢跑如果只是为了保证顺序，我更倾向

在前面的博客中，我有介绍过缓存一致性问题。本篇我打算详细分析各种情况，给出最优的解决方案：其中保证缓存一致性问题常有以下四种方式：1. 先更新缓存，再更新数据库2. 先更新数据库，再更新缓存3. 先删除缓存，再更新数据库4. 先更新数据库，再删除缓存场景一和场景二很少使用，因为都存在脏数据的可能性。导致原因基本类似：先进行的操作成功，但后进行的操作失败。一般线上更多使用场景三或者场景四对于场景三，单线程场景下可以保证缓存一致性，但多线程场景下仍有可能出现脏数据情况：线程a 是写请求

B 树实际都是从 AVL 树演化而来的，AVL 树由于二叉树的原因，总是不能摆脱每个节点只能保存一条数据的情况，查询效率总是 log2n，整体效率不高，在这种场景下提出了多叉树，减少磁盘 I/O 寻址次数，提高效率B 树实际就是 B- 树，这块是由于翻译问题...

一般情况下，线上每个 Redis 实例都包含从库，用来做读写分离，减轻主库的压力MySQL 的主从复制默认是异步的，其主要流程如下：1. 从节点的 I/O 线程连接主节点，并请求指定 bin log file 指定 position 之后的日志内容2. 主节点收到请求后，读取并返回。返回信息除了包含日志内容外还包含 bin log file 信息和 position 信息3. 从节点的 I/O 线程收到返回后，将接收到的日志内容更新到 relay log，并将 bin log file 信息和

InnoDB 四大特性如下：1. 插入缓存，Insert buffer2. 二次写，double write3. 自适应哈希索引，adaptive hash index4. 预读，read ahead-- --插入缓存索引数据存储在磁盘上，主键索引由于天然自增，无须磁盘的随机 I/O，只需不断追加即可。但普通索引大概率无序，默认情况下需要进行随机磁盘 I/O 操作，效率极差为了解决普通索引插入效率低下的问题，InnoDB 存储引擎引入 Insert Buffer 的概念，对于普通索

MySQL 三大范式属于一组规则，方便开发人员建立冗余小，结构合理的数据库第一范式：每一列都是不可再分的最小单位举个例子：某网购平台用户信息表通过地址字段记录客户地址，如陕西省西安市雁塔区XXX。系统为了按区域推荐商品需要多次获取用户所在省份，而省份信息实际在地址字段中已经保存过，但该字段还包含所在城市、小区等其它信息。此时也就说该字段不满足第一范式，实际可以将它拆分为三个字段：省、市、详细地址第二范式：每一列都与主键全部内容相关，而不是主键某一部分第二范式在第一范式的基础了做了增强，举个例子：订单

最开始，传统的 socket 模型效率极差，下面我通过伪代码描述整个过程：// 创建网络套接字s = socket();// 绑定端口及其它配置信息bind(s);// 开启监听listen(s);// 循环建立连接while (true) { // 建立连接 c = s.accept(listenfd); // 读取数据 int data = read(s, buf); // 处理数据 doSomethind(buf); // 断开连接 close(s);}...

同步和异步描述调用者会不会主动等待函数的返回值，举个例子：public void method() { int result = otherMethod();}像上面这种形式就叫同步，result 会一直等待 otherMethod() 方法执行完毕并拿到返回值public void method() { new Thread(() -> { int result = otherMethod(); });}像上面这种形式就叫异步，主线程不会等待 otherMethod() 方

二叉树：二叉树是一棵空树，或者是一棵由一个根节点和两棵互不相交的，分别称作根的左子树和右子树组成的非空树；左子树和右子树又同样都是二叉树完全二叉树：一棵深度为k的有n个结点的二叉树，对树中的结点按从上至下、从左到右的顺序进行编号，如果编号为 i 的结点与满二叉树中编号为 i 的结点在二叉树中的位置相同，则这棵二叉树称为完全二叉树满二叉树：在二叉树的基础上，满二叉树满足：除最后一层无任何子节点外，每一层上的所有结点都有两个子结点的二叉树二叉查找树（二叉搜索树、二叉排序树）二叉查找树

redis cluster 集群模式下执行批量处理命令会报错，具体原因如下：不同的 key 计算出的 slot 槽不一样，不同槽可能对应到不同节点，也就是说批量操作实际很可能被均分到不同的 redis 实例上，对于这种情况，redis cluster 没法处理，直接报错一般情况下有以下三种解决方法：1、别用批量处理命令，老老实实一条一条执行。怎么说呢，这种方式最简单，也最没有人用，因为根本不算解决方案，适合对性能要求不太高的场景2、在客户端计算槽，根据槽判断对应 key 属于那台 redis 实例，直

redis Pipeline 常用来解决批量处理问题：redis 只支持部分批量处理逻辑，对于其它绝大多数批量处理需要循环遍历依次执行，使用 Pipeline 就可以将多个命令封装再一起，一起发送给 redis 服务端，一起处理提到 Pipeline 就不得不说 redis 事务，因为它和事务很像：都是将多个命令打包，最后一起执行。这里我简单提一下两者区别：Pipeline 需要客户端、服务端一起参与，命令在客户端处打包，发送到服务端执行。而事务只需服务端参与，redis 通过维护队列保证事务中的指令

所谓事务是指不可分割的最小工作单位，要么全部执行成功，要么全部执行失败redis 事务从开始到结束需要经过三个阶段：事务开始：multi 命令开启一个事务命令入队：watch、multi、discard、exec 会被立即执行、其他命令依次入队并返回客户端 queued事务执行：exec 命令开始执行事务exec：执行事务discard：关闭事务watch：加分布式锁multi：开启事务QUEUED：命令入队成功一般情况下不建议使用 redis 事务，因为它不能保证原子性、不支持

count(*)：先把星号翻译为具体字段名字，多了一步翻译，效率差点count(1)：计算有多少符合条件的行，可以理解为每行数据存在某个值固定的字段，计算有多少个固定值从结果来说：count(*) 和 count(1) 没区别，都不会过滤 NULLcount(column) 会过滤 NULL从速度来说：如果只有一列，count(*) 效率最高多列时，count(1) 效率高于 count(*)如果列为主键，count(column) 效率最高如果列不为主键，count(1) 效率比

Java Object 类常用方法如下图所示：registerNatives()：注册 native 方法getClass()：获取 Class 类对象hashCode()：计算 hashCode 值equals()：比较对象是否相等clone()：克隆对象方法toString()：转字符串输出notify()：随机唤醒一个等待队列中的线程notifyAll()：唤醒所有等待队列中的线程wait()：放弃锁资源，进入等待队列finalize()：gc 收集时用到，唯一有可能复活的机会

左连接：select * from table_name t1 left join table_name t2 on t1.id = t2.id以左表每条数据为基础，去右表全表匹配，返回满足条件的数据，右表没找到显示 NULL右连接：select * from table_name t1 right join table_name t2 on t1.id = t2.id以右表每条数据为基础，去左表全表匹配，返回满足条件的数据，左表没找到显示 NULL内连接：select * from ta