引言

在很多应用场景下，我们都需要搜索功能，不管是在 App 中还是网站中。搜索每时每刻都在发生，比如搜索喜欢的零食、好看的衣服、喜欢的文章、想要学习的课程等等。如今要为我们的应用添加搜索已经非常容易了，早期我们可以使用 MySQL 的 MyISAM 存储引擎来做全文本搜索支持，不过今天要说的 Elasticsearch 同样可以做到，而且更强大。简单来说，Elasticsearch 是一个分布式搜索和分析引擎，也是众所周知的 ELK Stack 核心成员。它以 JSON 的格式存储文档到索引当中，能够高效地存储多种类型，并提供快速搜索的能力。此外，整个 ELK Stack 生态非常完善。

引言

应求开发一个简单的爬虫，用于从快递 100 抓取快递网点的分布，输入省份+城市+区县，然后是快递公司名称，抓取其对应的快递网点的信息（包括名称、地址、电话、坐标等）。说起来，开发这样一个简单的爬虫其实没什么难度，也没什么技术含量（没有时间要求、不需要分布式抓取、没什么反反爬策略加持等），不过这期间也遇到一些比较有趣的问题，特此记录下。

另外就是第一次接触了 pyecharts 这个数据可视化工具，用起来还挺方便的。样式配置好，还是会带来很好的视觉冲击的！当然，关键是利用这种工具有助于增加对抓取数据的理解（看具体需要的分析维度了）。

引言

在《Linux 系统编程手册》5.4 节，关于文件描述符和打开的文件关系是这样描述的：「内核为所有打开的文件维护了一个系统级的描述表（open file description table），有时也称之为打开文件表（open file table），并将表中的每个条目称为打开文件句柄（open file handle）。而针对每个进程，内核又为其维护了打开文件的描述符表（open file descriptor table）」。

引言

字典在 Redis 中是一个非常重要的数据结构，因为 Redis 本身就是一个键值数据库。我们先来回顾下在 Redis 源码学习之基本数据结构 中提到的 Redis 字典实现的一些特点：

1. 支持海量 <key, value> 存储；
2. 使用渐进式 Rehash 策略，避免因为需要迁移的 buckets 太多导致阻塞时间过久（Redis 核心处理逻辑是单线程模型）；
3. 默认使用 SipHash 算法计算键的 hash 值；
4. 对于哈希冲突问题，采用了常见的链地址法，且新加入的节点会插入到链表的头部；
5. 字典内部维护了两张哈希表，其中第二个哈希表会在扩容期间（Rehash）使用；
6. 提供了安全和非安全的迭代器，方便对整个字典进行迭代。

引言

Redis 底层的基础数据结构包括：动态字符串（sds）、跳表（skiplist）、压缩列表（ziplist）、字典（dict）、整数集合（intset），快速链表（quicklist）等，t_hash，t_set, t_zset, t_list 等对外类型的内部实现都依赖于这些数据结构，所以非常值得学习。