起步

状态模式属于行为型，旨在解决“反复出现”的设计问题。

“反复出现”你可以理解为一类状态会在程序运行过程中反复出现。并且，在不同状态下，状态持有者会表现出不同的行为。

起步

职责链模式属于行为型。它包含一系列处理对象，每个对象只处理它能够处理的请求——也就是每个处理对象的职责。而之所以叫职责链，是因为多个有职责的对象像链表似的连在一起。

起步

我着手一个需要高并发 update 的功能，进行压测时，发现了大量锁超时。于是所有矛头就指向我了，认为我做任务分发时重复分发了两个或两个以上相同的子任务。

这一假设基于现有的子任务 update 范围，已知更新语句走索引 c，则有：子任务 A 更新 c=[1,10] ；子任务 B 更新 c=[11,20] ... 子任务 N 更新 c=[n-9, n]。所以同事认为，只有可能会出现相同的 A 任务（B、C ... N 都行），才可能引发锁超时。

假设同事是正确的，那就意味着 update 只锁主符合条件的记录。但果真如此吗？

起步

由于我在新项目里引入了 python 的 async 语法，在连接 pg 数据库时用到了 asyncpg 这个异步包。多日来，从线上得到了一些反馈。简单说来就是：数据库存在暂时无法修复的 bug，使得一些 sql 成为 “禁用 sql”，从应用层看没有执行过 “禁用 sql” ，但在监控器上发现执行了 “禁用 sql”。

我简单跟踪了 asyncpg 源码，没有发现 asyncpg 包内部执行了 “禁用 sql ”，但同事仍对这个第三方包质疑。因为不懂得，所以不仁慈，可我必须做点什么为 asyncpg 洗冤……

起步

进行数十亿数据压测时，测试环境发生了一个很奇怪的现象：在对 SQLAlchemy 查出的结果做遍历操作时，随着集合越大，遍历的时间跟着变长，是肉眼可见的变长。

根据现象，一位腾讯的程序员向我提出了疑问：会不会遍历过程中 SQLAlchemy 又去查询了数据库？