布隆过滤器（英语：Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。
它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
Bitmap 原理及实现
所谓的 Bitmap 其实就是二进制位数组，由于元素是二进制位，每一个元素只占用1个bit，十分节省内存空间。
每一个bit有0、1两种状态，所以 Bitmap 适合应用于判断是否存在、桶排序（不含重复元素），具体来说可以用bitmap记录ip信息，实现布隆过滤器等等。
限流算法之漏桶与令牌桶
后端一个常见且比较让人头疼的问题是服务限流，没有做好限流开始导致单个服务耗时增加，进而影响上下游服务，最终可能导致整个系统被拖垮。
限流的目的是通过对并发请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务、排队 或等待、降级。
Redis原理 —— ziplist 压缩列表
压缩列表(ziplist)是列表和哈希的底层实现之一，是为尽可能地节约内存而设计的特殊编码双端链表。 当一个列表只包含少量列表项，并且每个列表项要么就是小整数值，要么就是长度比较短的字符串，那么Redis就会使用压缩列表来做列表键的底层实现。
压缩列表的优点是节省内存，缺点是插入元素的复杂度较高平均O(N)最坏O(N^2), 但是在小数据量的情况下，这种复杂度也是可以接受的。
Redis原理 —— SDS 简单动态字符串
Redis没有直接使用C语言传统的字符串表示，而是自己构建了一种名为简单动态字符串SD S(simple dynamic string)的数据结构 ，并将SDS用作Redis的默认字符串表示。
Redis内部所有字符串都由SDS来表示，其本质就是动态字节数组，和python的bytearray类似。
Redis原理 —— zskiplist 跳跃表
跳跃表 （skiplist) 是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的 指针，从而达到快速访问节点的目的。
跳跃表优点
- 表支持平均
O(logN), 最坏O(N)复杂度的节点查找，效率可以和平衡树相当 - 通过顺序性操作来批量处理节点
- 实现比平衡树要来得更为简单
因为ziplist内存占用较小，所以Redis使用作为有序集合的初始底层结构。
如果一个有序集合包含的元素数量比较多（大于zset-max-ziplist-entries），又或者有序集合中元素的成员是比较长的字符串时（大于zset-max-ziplist-value），Redis就会将其底层结构转换为跳跃表。
Redis原理 —— dict 字典
这是Redis源码阅读系列第一篇文章。
dict 是 redis 最重要的数据结构，db、hash、以及服务器内部需要用到hashmap的场景都是用dict来实现的。学习 dict 的源码，我们可以学到hashmap的原理及实现。
滴答清单与小米手环6 —— 近乎完美的番茄工作法方案
一直在寻找比较好的番茄工作法工具，但是都不那么满意。
物理番茄钟，主要问题是不够灵活，比如调整番茄时长，而且不能和GTD清单同步。
手机app的话，番茄钟结束的提醒声音过于吵闹，特别在公共场合，比如公司或者图书馆；如果静音或者震动的话，又常常感知不到，导致经常关注番茄钟时间，不能集中精力。
也用过安卓智能手表，但目前番茄工作法相关应用还是很少，没有找到合适的，而且手表续航太短，高强度使用基本得每天充电，心智负担大。
之前也用过手机番茄app配合手环，通过手环震动提醒番茄钟结束，方法可行，但是通知经常触达不到，体验不好。
最近小米手环6上市了，经过几天摸索，发现配合滴答清单的专注功能，以及小米穿戴的通知提醒，总体体验挺好，通知也准确，应当是目前最好的番茄工作法方案了。
xgboost C++线程安全问题定位与修复
公司的线上模型服务是基于brpc + xgboost实现的，而xgboost官方是不支持在多线程环境下使用的（1.2.0版本之前）
这个模型服务已经有两年多了，显然当时用的版本是不支持多线程的，有位同事当时修改了xgboost的源码，解决了多线程的问题，在线上也稳定运行到现在。
那么，问题来了。最近有个新需求，用到了xgboost的pred_leaf功能，然后就发现并发请求时0.1%的模型结果不对。
优雅地使用 Pizza Boy GBA 金手指
最近偶然又玩起了GBA游戏，瞬间又像是回到了儿时的时光。也碰到了许久以来的老问题，如何作弊，毕竟游戏里刷资源和练级实在是体力劳动，年龄大了毕竟肝不动了。
先说一下，我现在玩GBA的平台是安卓的Pizza Boy GBA模拟器加游戏手柄，总体游戏体验感觉比GBA真机还好，毕竟现在的设备机能放在这，而且还有倍速播放相关功能。
WSL2开启桥接网络
Windows Subsystem for Linux(WSL)从Version 1 (WSL1)升级到Version 2 (WSL2) 之后，底层实现方式发生了改变。
由于使用Hyper-V来实现WSL2，使得WSL更像虚拟机，一个能访问本地硬盘的虚拟机。
这带来一些便利，能够把它当做独立服务器来使用，可玩性就增强很多。当然，这也导致WSL上的端口不能从外部访问到，总之有利有弊。
虽然能够配置端口转发，曲线救国突破这个缺陷，但是有些服务的端口是约定俗成的（比如samba），更换端口号（原端口号被windows占用）之后其他设备可能识别不到服务。
经过一番思考后，觉得给WSL2开启桥接模式，直接连接物理网络才是相对最好的方案。