发表于 | 分类于

Hello 大家好，我是阿粉，作为 Java 工程师，数据库用的最多的肯定是 MySQL，而对于 MySQL 公号前面也发过很多文章，感兴趣的可以去翻翻。今天阿粉主要是想通过 LeetCode 上面的一个题目来再带大家看看 MySQL 的变量使用以及通过 Explain 的解析看看SQL 的执行过程。虽然平时在工作中对于 MySQL 使用的很多，但是相对于 MySQL 的变量使用相对还是较少的，所以阿粉在刚看到的时候还是有点懵的，不过我相信大家肯定不会像阿粉一样，毕竟能关注我们公众号的读者都是优秀的。

阅读全文 »

发表于 | 分类于

先说明这篇文章不包含任何广告内容，也不提供任何投资理财建议，股市有风险，投资需谨慎！

都说牛市来了，今年的 A 股的行情确实很不错，从上面的截图中可以看到阿粉的一只基金已经收益 90% 了。90% 是什么概念，估计连股神巴菲特都没有过，所以这几天阿粉慌的一批，除了慌的很之外，另一个就是懊悔的很，当初应该多买点的，只能说人性是贪婪的。

阅读全文 »

发表于 | 分类于

Hello,大家好，我是阿粉~

『上班 996，下班 ICU！』这是 2019 年上半年的热门事件，那个时候整个互联网圈子都在抵制 996，抵制无良公司。

不过随着 2020 年疫情开始，外部环境变得很差， 越来越多人无奈接受了 996 ，这个话题开始慢慢淡出了视野。

不过，最近两天 996 话题再次引爆互联网，又一上了热搜了，而事情的真实起因说起来真的令人心痛。

1 月 3 号下午，网友在脉脉平台爆料，拼多多员工在凌晨一点半下班回家路上晕倒猝死。

据网上爆料信息，这位拼多多员工是 98 年，年仅 22 岁，19 届毕业，内部花名润肺，从事拼多多新疆买菜项目的招商相关岗位。

2020 年的12 月 29 日凌晨一点半，下班路上突然晕倒，经过抢救无效去世。

事情爆料出来之后，热度越来越高，一晚上的时间该话题达到了近千万的热度，知乎话题被顶到热门，而微博 996 ，拼多多等话题也被顶上了热搜。

随后脉脉上又有内部员工爆料，拼多多 HR 正在开始删帖。

这个套路是不是很熟悉？

撤热搜，降热度，删帖子，互联网大厂对待大众舆论一套组合拳。

如果事情就到此为此，也许就没么魔幻！

2021 年 1 月 4 日早上，疑似拼多多官方知乎账号发表回应，不过 1 分钟之后就被秒删。

不过互联网都是有记忆的，许多知乎网友都看到这个回答，截图传播。

仔细看下这个回答，这什么意思❓❓❓

这是想表达 猝死=以命换钱=努力吗❓❓❓

这真的是经过脑子吗❓❓❓

随后 2020 年 1 月 4 号下午拼多多官方回应：“我们心痛如绞，我们爱你，深深的想念你。”

然后又进行辟谣，称其从未发布过上面的截图。

本来事情也许就到此为止了，官方都发声明辟谣了，但是网上那些截图真的是伪造吗？

如果真的是假的，那么作为这张截图的源头知乎，起码也要负相关的责任。

拼多多这是要把黑锅甩给知乎啊，不过知乎没怂，选择了硬刚。

知乎小管家拿出了后台数据，时间精确到了秒，啪啪打了拼多多的脸，砍了拼多多一刀。

不得不说，知乎🐂🍺。

事情的最后，拼多多最终发布道歉声明，把锅甩给了一个合作供应商的员工。

这个套路有没有感觉让人很熟悉❓❓❓

好像每次看到热点新闻，都是临时工默默抗下所有！

现在开始回顾一下这件事，拼多多这波公关，怎么说呢，真的……负分。

先是谎称官方好回答是谣言，被辟谣之后又说是营销合作方的锅，是他们在乱搞。

最后还让一个员工手写新来澄清。

一个官方的号都不能让人相信的话，这个官方号还有啥用，还有公信力吗？

建议早点换个公关团队吧。

拼多多为什么这么忙？

去年十月，拼多多五周年的时候，黄峥在内部发表称拼多多全员都要「开启硬核奋斗模式」。

什么是硬核奋斗模式？

很多大厂开始大小周的上班方案，相比这个，拼多多更加狠，据网上爆料拼多多推出超级版的大小周方案，大周 7 天，小周 6 天。

这么计算下来，每个月就休息两天。

另外据说拼多多买菜业务全年无休，今年的春节假期很有可能也是不放假！！！

这真的很硬核！！！

可能很多人不了解拼多多买菜业务，简单解释一下，其实就是社区团购业务，最近非常火热。

京东、滴滴、美团、阿里叫的上名的互联网大厂都来参了一手。

拼多多将买菜业务列为重点项目，倾其所有资源投入，All in 买菜。

也许正因为竞争太激烈，所有人都想在这个赛道抢到头筹，争取跑的比竞争对手快，所以开始无止尽的加班，无止尽压榨底层员工。

最后

其实写到这里，阿粉觉得真的有点无奈，身处现在互联网圈子，感觉个体力量真的很渺小。我们只能被资本摆布，只能逼着去 996。

不过即使这样，阿粉还是要发声，让这件事能被更多的读者看到。

哎，真的很痛心！希望这次事件能成为大家反抗 996 的一次契机。

最后提醒大家一下，真的要注意一下自己的身体健康，平时有时间的话还是要适当运动一下，毕竟身体是我们自己的。

阅读全文 »

发表于 | 分类于

Hello，大家好，我是阿粉~

上次我们分享 Redis 字符串的底层原理，今天我们再来看下 Redis List 列表的底层原理。

Redis List 命令

Redis List 列表支持的相关指令比较多，比如单个元素增加、删除操作，也支持多个元素范围操作。

Redis List 列表支持列表表头元素插入/弹出(LPUSH/LPOP)，也支持表尾元素插入/弹出(RPUSH/RPOP)。

另外 Redis List 列表还支持根据下标(LINDEX )获取元素，也支持根据根据下标覆盖相应的元素(LSET )。

除此之外，Redis List 列表还支持的范围操作，比如获取指定范围内全部元素(LRANGE )，移除指定范围内的全部元素(LTRIM )。

了解完的 Redis 相关指令，我们来看下 Redis List 列表底层实现方式，使用两种数据结构：

  • 压缩列表(ziplist)
  • 双向列表(linkedlist)

ps:本篇文章基于 Redis 3.2 开始进行讲解

双向列表(linkedlist)

上面我们知道了List 列表支持表头/表尾元素的插入/弹出，这类操作使用链表那就非常高效，时间复杂度为 O(1)。

Redis 双向列表(linkedlist) 由两个结构构成：

  • list
  • listnode

结构如下：

list 结构体中保存了表头节点，表尾节点以及链表包含的节点的数量，正因为如此操作表头/表尾元素的插入/弹出，链表长度的计算将会非常高效，时间复杂度为O(1)。

listnode结构体中除了保存节点的值以外，还会保存前后节点的指针，这样如果需要获取某个节点的前置节点与后置节点也会非常高效，时间复杂度为O(1)。

另外如果需要指定位置插入/删除元素，那么只需要变动当前位置节点前后指针即可，这个插入/删除操作复杂度为O(1)。

不过需要注意了，插入/删除动作前提我们需要找到这个指定位置，这个查找动作我们只能遍历链表，复杂度为O(N)，所以插入/删除的复杂度为O(N)。

双向列表(linkedlist)除了用作在列表键以外，还广泛用于发布/订阅，慢查询等内部操作。

既然双向列表(linkedlist)可以满足列表键的操作，那为什么 Redis 列表还采用其他的数据结构？

其实主要是因为内存占用问题，双向链表由于使用两个结构体，而这两个结构体都需要保存一些必要信息，这必然将会占用部分内存。

而当元素很少的时候，如果直接使用双向链表，内存还是比较浪费的。所以 Redis 引入压缩列表。

压缩列表

压缩列表是 Redis 为了节约内存而开发，它由一系列的特殊编码的的连续内存块组成的顺序型数据结构，整体结构如下：

从上面结构可以看出来，压缩列表实际上类似与我们使用的数组，数组中每一个元素保存一个数据。

不过与数组不同的是，压缩列表的表头存在三个字段

  • zlbytes 代表列表长度
  • zltail代表列表尾节点距离压缩列表起始地址的偏移量
  • zllen代表压缩列表的节点的个数

另外压缩列表的表尾还有一个字段，zlend里面保存一个特殊的值， OXFE，用于标记压缩列表的末端。

一个压缩列表可以由多个节点构成，每个节点可以保存整数值或字节数组，结构如下：

使用压缩列表，如果查找定位表头元素，我们只需要使用压缩列表起始地址加上表头三个字段长度就可以直接点位，查找非常快，复杂度是 O(1)。

而压缩列表的最后一个元素，查找起来也非常轻松，我们使用压缩列表起始地址加上zltail包含的长度就可以直接点位，查找也非常快，复杂度是 O(1)。

至于列表中的其他元素，就没有这么好运了，我们只能从第一个元素或者最后一个元素，遍历列表查找，此时的复杂度就是 O(N) 了。

另外压缩列表的新增、删除元素，都将会导致重新分配内存，效率不高，平均复杂度为 O(N)，最坏福复杂度为 O(N^2)。

编码转换

当我们创建一个 Redis 列表键，如果同时满足以下两个条件，列表对象将会使用压缩列表作为底层数据结构

  • 列表对象保存的所有字符串元素的长度都小于 64 字节
  • 列表对象中保存的元素数量小于 512 个

如果不能同时满足这两个条件，那么默认将会使用双向列表作为底层数据结构。

小结

Redis 列表底层使用两种数据结构，压缩列表与双向链表。

压缩列表由于使用了连续内存块，内存占用少，并且内存利用率高，但是新增、删除由于涉及重新分配内存，效率不高。

双向列表呢，新增、删除元素非常方便，但是由于每个节点都是独立的内存快，内存占用比较高，且内存碎片化严重。

这两种数据结构在表头/表尾插入与删除元素，都十分高效。但是其他操作，可能就效率较低。

所以我们使用 Redis 列表，一定要因地制宜，可以将其当做 FIFO 队列，这样仅使用 POP/PUSH ，效率将会很高。

参考资料

  1. Redis 设计与实现
阅读全文 »

发表于 | 分类于

Hello，大家好，我是阿粉~

无论你现在使用什么编程语言，每天最高频使用的应该就是字符串。可以说字符串对象很基础，也很重要。

那么今天想跟大家聊聊 Redis 字符串相关实现，来看下这个看起来简单的字符串，为什么实现起来确实不简单？

看完这篇文章你可以学到：

  • Redis 字符串对象多种数据结构
  • 底层数据结构转换关系
  • SDS 动态字符串
  • Redis 采用 C 语言实现，那么字符串为什么不直接使用 C 语言的字符串？

Redis 对象

每当我们在 Redis 中保存一对新的键值对时，Redis 至少会创建两个对象，一个对象用作保存键，而另一个对象用作保存值。

Redis 中每个对象都是一个 redisObject 结构，这个结构中有三个属性：

  • type，表示对象的类型
  • encoding，表示编码
  • pstr，指向底层数据结构的指针

type 代表对象类型，目前可以使用类型为：

  • 字符串对象
  • 列表对象
  • 哈希对象
  • 集合对象
  • 有序集合对象

我们可以使用 Redis 的 TYPE 指令，查看当前键对应值对象类型。

Redis 键对象说起来很简单，它总是是一个字符串对象，而值对象就相对复杂了，它可以是字符串，也可以是集合，也可以是字典等对象。

每个对象类型底层实现的时候将会采用了多种数据结构，而 encoding 代表底层数据结构类型：

我们可以使用 Redis 的 OBJECT ENCODING 指令查看一个当前键值对象底层的编码：

每个对象类型，可能支持多种数据结构，关系如下：

Redis 字符串对象

Redis 字符串对象底层支持三种数据结构，分别是(下面使用 OBJECT ENCODING 输出)：

  • int
  • embstr
  • raw

int 代表 long 类型的整数，只要字符串对象中保存的是一个整数值，就将会使用 int 。

这里需要注意，只有整数才会使用 int，如果是浮点数， Redis 内部其实先将浮点数转化为字符串值，然后再保存。

embstr 与 raw 类型底层的数据结构其实都是 SDS (简单动态字符串)，Redis 内部定义 sdshdr 一种结构。

那这两者的区别其实在于，embstr类型将会调用内存分配函数，分配一块连续的内存空间，空间中依次包含 redisObject 与 sdshdr 两个数据结构。

而 raw 类型将会调用两次内存分配函数，分配两块内存空间，一块用于包含 redisObject结构，而另一块用于包含 sdshdr 结构。

SDS 简单动态字符串

接下来我们来看下简单动态字符串。

sdshdr

sds 底层的结构包含三个属性：

  • len，用于记录下面 buf[] 数组已使用的长度，即等于 SDS 所保存的字符串长度
  • free，用于记录下面buf[] 数组未使用长度
  • buf[],用户保存字符串

这里我们需要注意了，buf[]数组中最后一个字节将会保存一个空字符 \0,代表字符串结束。sdshdr 结构中的 len 长度是没有包含这个这一个空字符。

这一点设计上与 C 语言的字符串相同。

SDS 扩容

当我们对 SDS 字符串进行增长操作，如果 SDS 空间不足，SDS 将会先进行扩容，然后再执行修改操作。

假设当前 SDS 值如下所示：

现在执行一次字符串拼接指令，

1
APPEND sds " Cluster"

由于拼接完成之后字符串总长度为 13，SDS 剩余空间不足，所以 SDS 将进行扩容，重新执行一次内存重分配。

由于我们上面的例子，SDS 修改之后的长度（即 len 属性值）小于 1MB，那么程序将会分配和 len 属性同样大小的未使用空间，此时 SDS 中 len 属性与 free 属性值相同。

此时 SDS buf 数组的实际长度为：

1
13+13+1=27

如果 SDS 修改之后长度大于 1MB，那么 Redis 将会分配 1MB的未使用空间。

假设进行修改之后，SDS len 属性变为 20MB，那么程序将会分配 1 MB 的未使用空间，此时 SDS buf 数组的实际长度为：

1
20MB+1MB+1byte

接着上面的例子，如果我们再次执行字符串拼接指令：

1
APPEND sds " Guide"

这次 SDS 未使用空间足够保存拼接字符串，所以这次不需要重新分配内存。

SDS 惰性空间释放

当我们对字符串进行缩减操作， SDS 字符串值将会被缩短，这样 SDS 剩余空间将会变多。

此时程序不会立即就使用内存分配函数回收多余空间，而是使用 free 属性记录多余空间，等待后面使用。

通过这种惰性空间释放策略，SDS 避免字符串缩短所需内存重分配操作，后续 SDS 字符串增长，可以直接使用多余的空间。

当然 SDS 也有相应的 API，可以真正释放 SDS 未使用的空间，所以不用担心惰性释放策略带来的内存浪费。

为什么 Redis 不直接使用 C 语言字符串？

Redis 底层使用 C 语言编程，那么其实 C 语言也有字符串，Redis 完全可以复用 C 语言字符串~

那么为什么 Redis 还要闭门造车，重新设计一个 SDS 数据结构呢？

这是因为 C 原因这种简单的字符串形式，在安全性，效率以及功能方面不满足 Redis 需求。

首先如果我们需要获取 C 语言字符串的长度，我们可以使用以下函数：

1
strlen(str)

strlen函数实际上使用遍历的方式，对每个字符计数，直到遇到代表字符串结束的空字符。

这个操作时间复杂度 O(N)。

而 SDS 由于 len 记录当前字符串的长度，所以直接读取即可，时间复杂度仅为 O(1)。

这就确保获取字符串长度的操作不会成为 Redis 性能瓶颈。

第二点每次增长或缩短 C 语言的字符串将会进行内存的重分配，否则可能导致缓冲区溢出，也有可能导致内存泄漏。

而 SDS 由于使用空间预分配的策略，如果 SDS 连续增长 N 次，内存重分配的次数从必定 N 次降低为最多 N 次。

第三点，C 语言字符串不能包含空字符，否则第一个空字符将会被误认为字符串结尾，这就大大限制使用的场景。

而 SDS 中由于可以使用 len 属性的值判断字符串是否结束，所以没有这种困扰。

所以 SDS 字符串是二进制安全的。

字符串对象底层数据结构转换

SDS 结构由于需要额外的属性记录长度以及未使用长度，虽然这样减少系统的复杂度，提高了性能，但是还是付出相应的代价，即存在一定内存空间浪费。

所以 Redis 字符串对象底层结构并不都是采用了 SDS。

如果字符串对象保存的是整数值，那么这个整数值将会直接保存在字符串对象结构的 ptr 属性。

如果保存不是整数，但是字符串长度小于等于 39 字节，那么字符串将会使用 embstr编码方式。 最后上述两个都不满足才会使用 raw 编码方式。

另外，int 编码与 embstr，在一定条件也将会转换为 raw 编码格式。

如果对底层整数执行追加操作，使其不再是一个整数，则字符串对象的编码就会从 int 变为 raw。

对于 embstr 编码，实际其实只读的，这是因为 Redis 底层并没有提供任何程序修改 embstr 编码对象。

所以一旦我们对embstr 编码字符串进行修改，字符串对象的编码就会从 embstr 变为 raw。

总结

Redis 字符串是我们平常操作最频繁的数据结构，了解底层字符串对象，对于我们了解 Redis 非常重要的。

Redis 字符串对象底层结构可以分为整数与 SDS，当我们在操作 set 命令保存整数时，就将会直接使用整数。

而 SDS 是 Redis 内部定义另一种结构，相比于 C 语言字符串，它可以快速计算字符串长度，不需要频繁的分配的内存，最终要一点 SDS 是一种二进制安全的字符串。

SDS 设计虽然带来的很多优势，但是这种结构相比于 C 语言，至少多占用 4(len)+4(free)=8 字节内存，如果 buf []数组还存在没有使用的空间，空间浪费更加严重。

所以 Redis 字符串不是万金油，某些场景下可能会占用大量内存。但是如果换一种数据结构，可能内存占用就会变少。

所以我们一定要基于合适场景使用合适的数据机构。

站在巨人的肩膀

  1. Redis 设计与实现
阅读全文 »