爱吃知识的土豆倪的博客

在这一章节，我们主要介绍两个部分，数据库相关概念及MySQL数据库的介绍、下载、安装、启动及连接。概念：约束是作用于表中字段上的规则，用于限制存储在表中的数据。目的：保证数据库中数据的正确、有效性和完整性。约束描述关键字非空约束限制该字段的数据不能为nullNOT NULL唯一约束保证该字段的所有数据都是唯一、不重复的UNIQUE主键约束主键是一行数据的唯一标识，要求非空且唯一PRIMARYKEY默认约束保存数据时，如果未指定该字段的值，则采用默认值DEFAULT。

模拟一个tcp服务器处理30个客户socket，一个监考老师监考多个学生，谁举手就应答谁。假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有下面几个选择：第一种选择：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有一个学生卡住，全班都会被耽误,你用循环挨个处理socket，根本不具有并发能力。第二种选择：你创建30个分身线程，每个分身线程检查一个学生的答案是否正确。这种类似于为每一个用户创建一个进程或者线程处理连接。

hash-max-listpack-entries：使用压缩列表保存时哈希集合中的最大元素个数。hash-max-listpack-value：使用压缩列表保存时哈希集合中单个元素的最大长度。Hash类型键的字段个数 小于 hash-max-listpack-entries且每个字段名和字段值的长度小于hash-max-listpack-value 时，Redis才会使用OBJ_ENCODING_LISTPACK来存储该键，前述条件任意一个不满足则会转换为 OBJ_ENCODING_HT的编码方式。

RedisObjectt内部对应的3大物理编码ziplist为了节省内存，采用了紧凑的连续存储。ziplist是一个双向链表，可以在时间复杂度为 O(1) 下从头部、尾部进行 pop 或 push。新增或更新元素可能会出现连锁更新现象(致命缺点导致被listpack替换)。不能保存过多的元素，否则查询效率就会降低，数量小和内容小的情况下可以使用。

每抢走一个红包就减少一个(类似减库存)，那这个就需要保证库存的-----------------------原子性，不加锁实现。给你100块，分成10个小红包(金额有可能小概率相同，有2个红包都是2.58)，总计有10个红包，抢一个少一个，总数显示(10/6)直到完，需要记录那些人抢到了红包，重复抢作弊不可以。2 一个总的大红包，会有可能拆分成多个小红包，总金额= 分金额1+分金额2+分金额3…3 每个人只能抢一次，你需要有记录，比如100块钱，被拆分成10个红包发出去，假设有10个人，红包总额100元。

定期删除策略的难点是确定删除操作执行的时长和频率：如果删除操作执行得太频繁或者执行的时间太长，定期删除策略就会退化成立即删除策略，以至于将CPU时间过多地消耗在删除过期键上面。因此，如果采用定期删除策略的话，服务器必须根据情况，合理地设置删除操作的。因为删除操作会占用cpu的时间，如果刚好碰上了cpu很忙的时候，比如正在做交集或排序等计算的时候，就会给cpu造成额外的压力，页面置换算法，淘汰最长时间未被使用的页面，看页面最后一次被使用到发生调度的时间长短，首先淘汰最长时间未被使用的页面。

线程 1 首先获取锁成功，将键值对写入 redis 的 master 节点，在 redis 将该键值对同步到 slave 节点之前，master 发生了故障；redis 触发故障转移，其中一个 slave 升级为新的 master，此时新上位的master并不包含线程1写入的键值对，因此线程 2 尝试获取锁也可以成功拿到锁，此时相当于有两个线程获取到了锁，可能会导致各种预期之外的情况发生，例如最常见的脏数据。

setnx，只能解决有无的问题，够用但是不完美hset，不但解决有无，还解决可重入synchronized单机版可以，但是上分布式死翘翘nginx分布式微服务单机锁不行如果取消宕机所，可以考虑上redis分布式锁setnx但是只是加了锁，没有释放锁，出现异常的话，可能无法释放锁，必须要在代码层面finally释放锁宕机了，部署了微服务代码层面根本没有走到finally这块，没办法保证解锁，这个key没有被删除，需要有lockkey的过期时间设定。

由一个初值都为零的bit数组和多个哈希函数构成，用来快速判断集合中是否存在某个元素目的减少内存占用方式不保存数据信息，只是在内存中做一个是否存在的标记flag本质上就是判断具体数据是否存在于一个大的集合中布隆过滤器（英语：Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制数组(00000000)+一系列随机hash算法映射函数，主要用于判断一个元素是否在集合中。

Unique Visitor 独立访客，一般理解为客户单ip，一般需要做去重考虑。Page View 页面浏览量，不需要考虑去重Daily Active User 日活跃用户量：登陆或者使用了某个产品的用户数（去掉重复登陆的用户）常用于反应网站、互联网应用或者网络游戏的运营情况Monthly Active User：月活跃用户量。

1 比较懒，什么都不做，之前对mysql做了数据新增，利用redis的回写机制，让它逐步实现100条新增记录的同步，最好提前晚上部署发布版本的时候，由自己人提前做一次，让redis同步了，不要把这个问题留给客户。请求去查询一条记录，先插redis无，后查mysql无，都查询不到该条记录，但是请求每次都会打到数据库上面去，导致后台数据库压力暴增，这种现象我们成为缓存穿透，这个redis变成了一个摆设。简单说就是，本来无一物，两库都没有，机不再redis缓存库，也不再mysql，数据库存在被多次暴击风险。

需要注意的是，RDB 是默认持久化方式，但 Redis 允许 RDB 与 AOF 两种持久化技术同时开启，此时系统会使用 AOF 方式做持久化，即 AOF 持久化技术的优先级要更高。在持久化时，先将 SOF、rdb_version 及内存数据库中的数据快照这三者的二进制数据拼接起来，形成一个二进制数（假设称为数 a），然后再使用这个 a 除以校验和 check_sum，此时可获取到一个余数 b，然后再将这个 b 拼接到 a 的后面，形成 databases。不同的持久化方式，其数据的丢失率也是不同的。

👏作者简介：大家好，我是爱吃芝士的土豆倪，24届校招生Java选手，很高兴认识大家 📕系列专栏：Spring源码、JUC源码、Kafka原理、分布式技术原理、数据库技术 🔥如果感觉博主的文章还不错的话，请👍三连支持👍一下博主哦 🍂博主正在努力完成2023计划中：源码溯源，一探究竟 📝联系方式：nhs19990716，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬👀 文章目录缓存双写一致性问题经典面试题引入缓存双写一致性的理解如何写数据库和缓存一致性的几种更新策略目的可以停机的情况四种更新策略先

给出每种数据结构Top 1 bigkey，同时给出每种数据类型的键值个数+平均大小。

模拟一个tcp服务器处理30个客户socket。第一种选择(轮询)：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有一个学生卡住，全班都会被耽误,你用循环挨个处理socket，根本不具有并发能力。第二种选择(来一个new一个，1对1服务)：你创建30个分身线程，每个分身线程检查一个学生的答案是否正确。这种类似于为每一个用户创建一个进程或者线程处理连接。第三种选择(响应式处理，1对多服务)，你站在讲台上等，谁解答完谁举手。

在之前的测试中，我们发现，如果数据量很大，在执行count操作时，是非常耗时的。MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候会直接返回这个数，效率很高；但是如果是带条件的count，MyISAM也慢。InnoDB 引擎就麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。如果说要大幅度提升。

索引（index）是帮助MySQL高效获取数据的数据结构(有序)。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。索引结构描述B+Tree索引最常见的索引类型，大部分引擎都支持 B+ 树索引Hash索引底层数据结构是用哈希表实现的, 只有精确匹配索引列的查询才有效, 不支持范围查询。

BitMap 是 Redis 2.2.0 版本中引入的一种新的数据类型。该数据类型本质上就是一个仅包含 0 和 1 的二进制字符串。而其所有相关命令都是对这个字符串二进制位的操作。用于描述该字符串的属性有三个：key、offset、bitValue。key：BitMap 是 Redis 的 key-value 中的一种 Value 的数据类型，所以该 Value 一定有其对应的 key。offset：每个 BitMap 数据都是一个字符串，字符串中的每个字符都有其对应的索引，该索引从 0 开始计数。

无论是 Redis 的 Key 还是 Value，其基础数据类型都是字符串。例如，Hash 型 Value 的field 与 value 的类型、List 型、Set 型、ZSet 型 Value 的元素的类型等都是字符串。虽然 Redis是使用标准 C 语言开发的，但并没有直接使用 C 语言中传统的字符串表示，而是自定义了一种字符串。这种字符串本身的结构比较简单，但功能却非常强大，称为简单动态字符串，Simple Dynamic String，简称 SDS。

👏作者简介：大家好，我是爱吃芝士的土豆倪，24届校招生Java选手，很高兴认识大家 📕系列专栏：Spring源码、JUC源码、Kafka原理、分布式技术原理、数据库技术 🔥如果感觉博主的文章还不错的话，请👍三连支持👍一下博主哦 🍂博主正在努力完成2023计划中：源码溯源，一探究竟 📝联系方式：nhs19990716，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬👀 文章目录分库分表介绍问题分析拆分策略垂直拆分水平拆分实现技术MyCat概述介绍下载安装目录介绍概念介绍MyCat入门需求环境准备配

MySQL5.5 版本开始，默认使用InnoDB存储引擎，它擅长事务处理，具有崩溃恢复特性，在日常开发中使用非常广泛。下面是InnoDB架构图，左侧为内存结构，右侧为磁盘结构。当我们创建了上面的这张表，我们在查看表结构的时候，就可以显式的看到这三个字段。隐藏字段含义DB_TRX_ID最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID。回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本。DB_ROW_ID隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。