乍看书名以为是关于如何做笔记的工具书，后面发现重点是讲写作思维方式，整体内容上比看之前的预期好很多。卡片盒写作法是卢曼杰出学术成就的生产力来源，他在长达 30 多年的研究中出版了 58 本著作以及数百篇文章。书中主要是论述如何通过卡片笔记的方法进行写作，也顺便解答了我的几个问题:

This article gives a brief introduction into monitoring Go applications using OpenTelemetry and Uptrace.

大部分开发对 Bitmap 应该都不陌生，除了作为 Bloom Filter 实现的存储之外，许多数据库也有提供 Bitmap 类型的索引。对于内存型的存储来说，Bitmap 只是一个特殊类型(bit)的稀疏数组，操作内存不会带来读写放大问题(指的是物理读写的数据量远大于逻辑的数据量), Redis 就是在字符串类型上支持 bit 的相关操作，而对于 Kvrocks 这种基于磁盘 KV 实现的存储则会是比较大挑战，本篇文章主要讨论的其实是「基于磁盘 KV 实现 Bitmap 要如何减少磁盘读写放大」

Kvrocks 是基于 RocksDB 之上兼容 Redis 协议的 NoSQL 存储服务，设计目标是提供一个低成本以及大容量的 Redis 服务，作为 Redis 在大数据量场景的互补服务，选择兼容 Redis 协议是因为简单易用且业务迁移成本低。目前线上使用的公司包含: 美图、携程、百度以及白山云等，在线上经过两年多大规模实例的验证。

项目核心功能包含:

• 兼容 Redis 协议
• 支持主从复制
• 支持通过 Namespace 隔离不同业务的数据
• 高可用，支持 Redis Sentinel 自动主从切换
• 集群模式 (进行中，预计在 7-8 月份完成)

GitHub地址：https://github.com/bitleak/kvrocks

美图 PHP 业务团队在使用 php-memcached 扩展陆陆续续遇到一些隐蔽的 ”坑”，而这些坑在 php-memcached 也是比较容易踩到。其中有如 TCP_NODELAY 这类常见的坑，也有一些 php-memcached 本身设计带来的问题。这里分享出来希望可以给遇到类似问题或者正在坑里的同学带来一些帮助。

tcpkit 是支持用 lua 脚本分析网络数据包的工具，附带简单协议解析(Redis/Memcached)和延时统计。最早开发 tcpkit 主要原因是经常需要通过网络包来分析资源慢请求问题，在数据包量比较大的场景下人肉分析会浪费比较时间，所以希望可以通过编码的方式来分析这类问题。从开发至今已经帮助我们团队以及美图 DBA 定位无数的线上问题，之前甚至通过 tcpkit 找到了 BCM 网卡驱动到 kernel 偶发产生几百毫秒延时问题。

Github 地址: https://github.com/git-hulk/tcpkit

lmstfy(Let Me Schedule Task For You) 是美图架构基础服务团队在 2018 年初基于 Redis 实现的简单任务队列(Task Queue)服务，目前在美图多个线上产品使用接近两年的时间。主要提供以下特性:

• 任务具备延时、自动重试、优先级以及过期等功能
• 通过 HTTP restful API 提供服务
• 具备横向扩展能力
• 丰富的业务和性能指标

Github 项目地址: https://github.com/meitu/lmstfy

前天晚上不经意间在 youtube 上面看到 Redis 作者 Salvatore 在 RedisConf 2019 分享，其中一段展示了 Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上，内心很是激动，迫不及待地去看了一下相关的代码实现。

目前对于单线程 Redis 来说，性能瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:

1. 提高网络 IO 性能，典型的实现像使用 DPDK 来替代内核网络栈的方式
2. 使用多线程充分利用多核，典型的实现像 Memcached

美图在 2017 年下半年开始计划做 Redis/Memcached 资源 PaaS 平台，而 PaaS 化之后面临一个问题是如何实现资源缩容/扩容对业务无感，为了解决这个问题，美图技术团队于 17 年 11 月引入 twemproxy 作为资源网关。

但是长期的实践中，其开源版本不能完全适应美图的实际情况，其主要存在单线程模型无法利用多核，性能不佳；配置无法在线 Reload ；Redis 不支持主从模式；无延时指标等问题，所以美图技术团队对其进行了相应的改造。我们基于之上实现了多进程以及配置在线更新的功能，同时增加了一些延时的相关监控指标。

本文将为大家详细讲解 twemproxy 实现以及相应地改造，希望能给其他的技术团队提供一些可以借鉴的经验。

对于 Redis 这种单线程模型的服务来说，一些耗时的命令阻塞其他请求是个头痛的问题。典型的命令如 KEYS/FLUSHALL/FLUSHDB 等等，一般线上也会禁用这些会遍历整个库的命令。而像 DEL/LRANGE/HGETALL 这些可能导致阻塞的命令经常被工程师忽视，这些命令在 value 比较大的时候跟 KEYS 这些并没有本质区别。

Redis 4.0 开始针对 DEL/FLUSHALL/FLUSHDB 做了一些优化。