这不是一本教你练出“可爱肌肉”的书，而是一本教你练出能用的力量、极限的力量、生存的力量的书。
作者保罗·威德在美国最严酷的监狱中度过了19年，在其中逐渐挖掘出了一套最古老的健身法，在商业社会中早已失传的力量哲学，并凭此成为了地球上最强壮的人之一。

本文是用于速查囚徒健身”六艺”的手册

分布式系统中，全局唯一id的生成是个常见的问题。在互联网的业务系统中，涉及到各种各样的ID，如在支付系统中就会有支付ID、退款ID等。

一致性哈希是一种特殊的哈希算法。在使用一致哈希算法后，哈希表槽位(slots)数的改变平均只需要对 K/n 个key需要重新映射，其中K是key的数量，n是槽位数量。然而在传统的哈希表中，添加或删除一个槽位的几乎需要对所有关键字进行重新映射。

谈到一致性哈希（Consistent hashing），就得先讲一下分布式存储。
比如我们有2000w条数据，一台机器存不下，那么我们可以把分成10份每份200w条存到10台机器上。
这样存储就不成问题，但是查询效率很低，查一条数据要每台机器都查一遍。
如果这些数据能够分类，每一类存到一台机器上，查询前先知道数据的类别，就可以直接定位到某台机器，效率就高了。

布隆过滤器（英语：Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。

它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

所谓的 Bitmap 其实就是二进制位数组，由于元素是二进制位，每一个元素只占用1个bit，十分节省内存空间。

每一个bit有0、1两种状态，所以 Bitmap 适合应用于判断是否存在、桶排序（不含重复元素），具体来说可以用bitmap记录ip信息，实现布隆过滤器等等。

后端一个常见且比较让人头疼的问题是服务限流，没有做好限流开始导致单个服务耗时增加，进而影响上下游服务，最终可能导致整个系统被拖垮。

限流的目的是通过对并发请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务、排队 或等待、降级。

压缩列表(ziplist)是列表和哈希的底层实现之一，是为尽可能地节约内存而设计的特殊编码双端链表。 当一个列表只包含少量列表项，并且每个列表项要么就是小整数值，要么就是长度比较短的字符串，那么Redis就会使用压缩列表来做列表键的底层实现。

压缩列表的优点是节省内存，缺点是插入元素的复杂度较高平均O(N)最坏O(N^2), 但是在小数据量的情况下，这种复杂度也是可以接受的。

Redis没有直接使用C语言传统的字符串表示，而是自己构建了一种名为简单动态字符串SD S(simple dynamic string)的数据结构 ，并将SDS用作Redis的默认字符串表示。

Redis内部所有字符串都由SDS来表示，其本质就是动态字节数组，和python的bytearray类似。

跳跃表 （skiplist) 是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的 指针，从而达到快速访问节点的目的。

跳跃表优点

• 表支持平均O(logN), 最坏O(N)复杂度的节点查找，效率可以和平衡树相当
• 通过顺序性操作来批量处理节点
• 实现比平衡树要来得更为简单

因为ziplist内存占用较小，所以Redis使用作为有序集合的初始底层结构。
如果一个有序集合包含的元素数量比较多（大于zset-max-ziplist-entries），又或者有序集合中元素的成员是比较长的字符串时（大于zset-max-ziplist-value），Redis就会将其底层结构转换为跳跃表。

这是Redis源码阅读系列第一篇文章。

dict 是 redis 最重要的数据结构，db、hash、以及服务器内部需要用到hashmap的场景都是用dict来实现的。学习 dict 的源码，我们可以学到hashmap的原理及实现。

一直在寻找比较好的番茄工作法工具，但是都不那么满意。

物理番茄钟，主要问题是不够灵活，比如调整番茄时长，而且不能和GTD清单同步。

手机app的话，番茄钟结束的提醒声音过于吵闹，特别在公共场合，比如公司或者图书馆；如果静音或者震动的话，又常常感知不到，导致经常关注番茄钟时间，不能集中精力。

也用过安卓智能手表，但目前番茄工作法相关应用还是很少，没有找到合适的，而且手表续航太短，高强度使用基本得每天充电，心智负担大。

之前也用过手机番茄app配合手环，通过手环震动提醒番茄钟结束，方法可行，但是通知经常触达不到，体验不好。

最近小米手环6上市了，经过几天摸索，发现配合滴答清单的专注功能，以及小米穿戴的通知提醒，总体体验挺好，通知也准确，应当是目前最好的番茄工作法方案了。

话接上文，还是这个 C++ 模型服务，在并发请求的情况下，大概有0.01%的请求部分模型分数不对。定位这种问题，对一个Python程序员来说，真是苦手。还好，经过调整代码不断测试，最终完美解决了问题。

公司的线上模型服务是基于brpc + xgboost实现的，而xgboost官方是不支持在多线程环境下使用的（1.2.0版本之前）

这个模型服务已经有两年多了，显然当时用的版本是不支持多线程的，有位同事当时修改了xgboost的源码，解决了多线程的问题，在线上也稳定运行到现在。

那么，问题来了。最近有个新需求，用到了xgboost的pred_leaf功能，然后就发现并发请求时0.1%的模型结果不对。

最近偶然又玩起了GBA游戏，瞬间又像是回到了儿时的时光。也碰到了许久以来的老问题，如何作弊，毕竟游戏里刷资源和练级实在是体力劳动，年龄大了毕竟肝不动了。

先说一下，我现在玩GBA的平台是安卓的Pizza Boy GBA模拟器加游戏手柄，总体游戏体验感觉比GBA真机还好，毕竟现在的设备机能放在这，而且还有倍速播放相关功能。

NAS的文件系统一直是我比较纠结的一个点。NAS的系统基本上是基于Linux(Unix)，文件系统不是ntfs，数据迁移不方便，数据恢复工具也没那么全。

WSL就完美解决了这个问题，用Linux提供服务，数据最终还是落在ntfs上，而且重要的是everything也能用上。

openmediavault(OMV)是一个基于Debian的NAS系统，而且能在原生Debian系统上自行安装，正好能够实现我们的功能。