Michael's Blog

什么是缓存击穿？ 其实跟缓存雪崩有点类似，缓存雪崩是大规模的key失效，而缓存击穿是一个热点的Key，有大并发集中对其进行访问，突然间这个Key失效了，导致大并发全部打在数据库上，导致数据库压力剧增。这种现象就叫做缓存击穿。 分析： 关键在于某个热点的key失效了，导致大并发集中打在数据库上。所以要从两个方面解决，第一是否可以考虑热点key不设置过期时间，第二是否可以考虑降低打在数据库上的请求数量。 解决方案： 1、上面说过了，如果业务允许的话，对于热点的key可以设置永不过期的key。 2、使用互斥锁。如果缓存失效的情况，只有拿到锁才可以查询数据库，降低了在同一时刻打在数据库上的请求，防止数据库打死。当然这样会导致系统的性能变差。

转自 特性 ActiveMQ RabbitMQ RocketMQ Kafka 单机吞吐量 万级，比 RocketMQ、Kafka 低一个数量级 同 ActiveMQ 10 万级，支撑高吞吐 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 topic 数量对吞吐量的影响 topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源 时效性 ms 级 微秒级，这是 RabbitMQ 的一大特点，延迟最低 ms 级 延迟在 ms 级以内 可用性 高，基于主从架构实现高可用 同 ActiveMQ 非常高，分布式架构 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 消息可靠性 有较低的概率丢失数据 基本不丢 经过参数优化配置，可以做到 0 丢失...

使用kafka可以对系统 ​ 解耦、 ​ 流量削峰、 ​ 缓冲 可以实现系统间的异步通信等。 在活动追踪、消息传递、度量指标、日志记录和流式处理等场景中非常适合使用kafka。 组件 释义 备注 Broker 服务代理节点 其实就是一个kafka实例或服务节点，多个broker构成了kafka cluster Producer 生产者 也就是写入消息的一方，将消息写入broker中 Consumer 消费者 也就是读取消息的一方，从broker中读取消息 Consumer Group 消费组 一个或多个消费者构成一个消费组，不同的消费组可以订阅同一个主题的消息且互不影响 ZooKeeper kafka使用zookeeper来管理集群的元数据，以及控制器的选举等操作 Topic 主题 每一个消息都属于某个主题，kafka通过主题来划分消息，是一个逻辑上的分类。 Partition 分区 同一个主题下的消息还可以继续分成多个分区，一个分区只属于一个主题 Replica 副本 一个分区可以有多个副本来提高容灾性。 Leader and F...

通过explain，如以下例子： 1EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND title='Senior Engineer' AND from_date='1986-06-26'; id select_type table partitions type possible_keys key key_len ref filtered rows Extra 1 SIMPLE titles null const PRIMARY PRIMARY 59 const,const,const 10 1 id：在⼀个⼤的查询语句中每个SELECT关键字都对应⼀个唯⼀的id ，如 explain select * from s1 where id = (select id from s1 where name = 'egon1'); 第一个select的id是1，第二个select的id是2。 有时候会出现两个sel...

MVCC叫做多版本控制，实现MVCC时用到了一致性视图，用于支持读提交和可重复读的实现。 对于一行数据若是想实现可重复读取或者能够读取数据的另一个事务未提交前的原始值，那么必须对原始数据进行保存或者对更新操作进行保存，这样才能够查询到原始值。 在Mysql的MVCC中规定每一行数据都有多个不同的版本，一个事务更新操作完后就生成一个新的版本，并不是对全部数据的全量备份，因为全量备份的代价太大了： 如图中所示，假如三个事务更新了同一行数据，那么就会有对应的v1、v2、v3三个数据版本，每一个事务在开始的时候都获得一个唯一的事务id（transaction id），并且是顺序递增的，并且这个事务id最后会赋值给row trx_id，这样就形成了一个唯一的一行数据版本。 实际上版本1、版本2并非实际物理存在的，而图中的U1和U2实际就是undo log日志（回滚日志），这v1和v2版本是根据当前v3和undo log计算出来的。 InnoDB引擎就是利用每行数据有多个版本的特性，实现了秒级创建“快照”，并不需要花费大量的是时间。

常见 HTTP 状态码，分别代表什么含义 状态码 含义 1xx 消息临时响应 2xx 成功 3xx 重定向 4xx 客户端错误 5xx 服务器错误 HTTP状态码列表 状态码 状态码英文名称 中文描述 100 Continue 继续。客户端应继续其请求 101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 200 OK 请求成功。一般用于GET与POST请求 201 Created 已创建。成功请求并创建了新的资源 202 Accepted 已接受。已经接受请求，但未处理完成 203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 205 Reset Content 重置内容。服务器处理成功，用户终端（例...

主从同步 master主库，有数据更新，将此次更新的事件类型写入到主库的binlog文件中 主库会创建log dump 线程通知slave有数据更新 slave从库，向master节点的 log dump线程请求一份指定binlog文件位置的副本，并将请求回来的binlog存到本地的Relay log 中继日志中 slave 再开启一个SQL 线程读取Relay log事件，并在本地执行redo操作。将发生在主库的事件在本地重新执行一遍，从而保证主从数据同步 主从延迟 指一个写入SQL操作在主库执行完后，将数据完整同步到从库会有一个时间差，称之为主从延迟。 主库生成一条写入SQL的binlog，里面会有一个时间字段，记录写入的时间戳 t1 binlog 同步到从库后，一旦开始执行，取当前时间 t2 t2-t1，就是延迟时间 注意：不同服务器要保持时钟一致。 主从延迟排查方法 通过 show slave status 命令输出的Seconds_Behind_Master参数的值来判断 为零：表示主从复制良好 正值：表示主从已经出现延时，数字越大，表示从库延迟...

主键使用自增ID还是UUID?能说说原因吗？ 自增ID和UUID作为主键的考虑主要有两方面， 一个是性能 另一个就是存储的空间大小， 一般没有特定的业务要求都不推荐使用UUID作为主键。 因为使用UUID作为主键插入并不能保证插入是有序的，有可能会涉及数据的挪动，也有可能触发数据页的分裂，因为一个数据页的大小就是16KB，这样插入数据的成本就会比较高。 而自增ID作为主键的话插入数据都是追加操作，不会有数据的移动以及数据页的分裂，性能会比较好。 另一方面就是存储空间， 自增主键一般整形只要4个字节，长整形才占8字节的大小空间， 而使用UUID作为主键存储空间需要16字节的大小，会占用更多的磁盘， 在二级索引中也会存出一份主键索引，这样多占用消耗的空间就是两倍，性能低， 所以不推荐使用。 自增id是连续的，插入过程也是顺序的，总是插入在最后，减少了页分裂，有效减少数据的移动。 所以尽量不要使用字符串（如：UUID）作为主键。

分库分表 ​ 并发量决定是否需要分库， ​ 数据量决定是否需要分表。 分区分片 ​ 按时间范围归档分区 ​ 按用户ID取模分表， ​ 按shardingkey来分片； 数据量太大的场景 mysql表的数据量一般控制在千万级别，如果再大的话，就要考虑分库分表。 除了分表外，列举了面对海量数据业务的一些常见优化手段 缓存加速 读写分离 垂直拆分 分库分表 冷热数据分离 ES助力复杂搜索 NoSQL NewSQL 分表后ID如何保证全局唯一 分库分表后，多张表共用一套全局id，原来单表主键自增方式满足不了要求。 我们需要重新设计一套id生成器。 特点：全局唯一、高性能、高可用、方便接入。 UUID 数据库自增ID 数据库的号段模式，每个业务定义起始值、步长，一次拉取多个id号码 基于Redis，通过incr命令实现ID的原子性自增。 雪花算法（Snowflake） 市面的一些开源框架，如：百度（uid-generator），美团（Leaf）， 滴滴（Tinyid）等 分表后可能遇到的问题 分表后，与单表的最大区别是有分表键sharding_key，用来路由具...

Mysql内部通过锁机制实现对资源的并发访问控制，保证数据的一致性，锁机制的类型和引擎的种类有关，MyISAM中默认支持的表级锁有两种：共享读锁和独占写锁。表级锁在MyISAM和InnoDB的存储引擎中都支持，但是InnoDB默认支持的是行锁。 MyISAM锁机制Mysql中可以通过以下sql来显示的在事务中显式的进行加锁和解锁操作： 123456// 显式的添加表级读锁LOCK TABLE 表名 READ// 显示的添加表级写锁LOCK TABLE 表名 WRITE// 显式的解锁（当一个事务commit的时候也会自动解锁）unlock tables; （1）MyISAM表级写锁：当一个线程获取到表级写锁后，只能由该线程对表进行读写操作，别的线程必须等待该线程释放锁以后才能操作。 （2）MyISAM表级共享读锁：当一个线程获取到表级读锁后，该线程只能读取数据不能修改数据，其它线程也只能加读锁，不能加写锁。 InnoDB锁机制InnoDB和MyISAM不同的是，InnoDB支持行锁和事务，InnoDB中除了有表锁和行级锁的概念，还有Gap Lock（间隙锁）、Next-key ...