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系统上自行安装，正好能够实现我们的功能。

Windows Subsystem for Linux(WSL)从Version 1 (WSL1)升级到Version 2 (WSL2) 之后，底层实现方式发生了改变。

由于使用Hyper-V来实现WSL2，使得WSL更像虚拟机，一个能访问本地硬盘的虚拟机。
这带来一些便利，能够把它当做独立服务器来使用，可玩性就增强很多。当然，这也导致WSL上的端口不能从外部访问到，总之有利有弊。

虽然能够配置端口转发，曲线救国突破这个缺陷，但是有些服务的端口是约定俗成的（比如samba），更换端口号（原端口号被windows占用）之后其他设备可能识别不到服务。

经过一番思考后，觉得给WSL2开启桥接模式，直接连接物理网络才是相对最好的方案。

非常时期，三观频繁受到冲击，估计以后历史会说今年是美利坚由盛转衰的一年。

年初疫情到年尾还没消停，却也是多了时间积累，多磨砺自己。君子藏器于身，待时而动。

另一个，依然常年与懈怠和懦弱斗争，不说屡战屡败，已不远矣。戒之戒之

由于Python解释器是由C语言编写，我们可以使用GDB来调试Python进程，对于程序卡死等异常情况调试比较有帮助。

缘起

我家里的路由器是矿渣newifi3, 刷了OpenWrt系统，可玩性还是非常强的。
而且路由器作为24小时在线的设备，很适合作为网络设备的控制中心，比如使用WOL唤醒其他设备。
之前就写过一个Python服务，用来控制其他设备的唤醒和睡眠。但是由于newifi3的rom空间十分有限，usb又十分不稳定，Python环境在路由器上还是太重了。
所以就想到了利用路由器默认的uhttpd网页服务器，自己编写CGI脚本来实现相应功能。

在玩树莓派的过程中难免会碰到如何高效的备份系统的问题。

由于树莓派用的是Linux系统，所以常见的有两种备份方式

1. 基于文件的备份，比如tar，rsync
2. 基于磁盘的备份，比如dd

这两种备份方式各有利弊：
基于文件的备份占用空间小，而且可以在系统在线时操作，比较方便，但是当要还原整个系统时就会比较麻烦（引导重建等等）。
基于磁盘的备份就比较简单粗暴了，直接克隆硬盘，恢复时直接还原映像文件就好了，但是由于是整盘备份，空间占用比较大。

平时例行午睡时间是下午1:20-1:50，今天也一样，只是闹钟响的时候感觉没睡够。
于是想再眯一会儿，然后我睡朦了，做了一个让我哭笑不得的梦。

下面描述下这个梦

在梦中，我被一阵持续的噪音惊醒，声音类似老式空调压缩机的声音，嘈杂而持久，整个房间都有一点震动的感觉。我在房间里仔细搜寻噪音的源头，好让自己再次入眠。

找来找去，发现我的冲牙器在不停震动，声音也很是类似，还以为忘记关开关了。于是准备把开关关了，一阵手忙脚乱开关还是没能关掉（梦中这种细致的操作不好实现？）。于是我把冲牙器的插头拔下了，但是它好像没有停下来的意思，还在不停震动着，而且冲牙器的位置也不是现实中的位置，我好似也坦然接受了这无须电源的震动（这好像不是重点），但是又无法确定噪音的源头就是它。

然后，富有逻辑的操作来了，我找了个桶把冲牙器盖起来，发现噪音并没有减弱，于是我排除了它的嫌疑。

接着就发现应该是空调的压缩机在响，我就认定是它了，然后空调的指示灯变清晰了，原来是我误开了空调，我笃定开得是制热，只有制热需要这么大的功率，空气也燥热起来，一切是那么符合逻辑。

心满意足找到答案之后，我醒了，发现噪音来源是外面修路的水泵。