数据结构
这里记录一些常用的高级数据结构，目的是提升自身使用姿势，做查漏补缺。 数据结构 1. cuckoo hash 为了解决hash冲突问题。 常规的解决hash冲突的方法是拉链法，有冲突的就接在链表后。比如java的hashMap就是用数组+链表 实现的 思路：多哈希函数，减少hash冲突概率。 适用于：读多写少的场景。（因为布谷鸟hash查两次必出结果，但拉链hash查多少次取决于拉链长度） []*Node + 多个hash方法（初始是2） 插入key：计算 hash1(key), hash2(key) ，任一位置为空即可插入；若都不为空，则随机占领一个位置，把原key’做剔除，key’按一样步骤选择自己的新位置。如果key’选新位置时仍然被占满，则继续剔除。 如果剔除次数超过阈值，则认为数组太满了，需要 添加新的hash函数+扩容+做rehash 读取key：计算 hash1(key), hash2(key) if arr[idx]==key 则返回 删除key：先读取，再清除 2. bloom filter 为了查询海量数据中是否存在某数据。...
我与规则引擎
我在字节跳动工作期间有一半时间在搞内容安全方向，内容安全工程上的核心之一是策略的管控。策略平台也是我的工作主内容，因此想单开一篇文章来回顾。 当谈到规则引擎的时候，往往可以由浅入深分成这么几个概念： 规则引擎库 规则引擎服务 策略平台 执行引擎 接下来，我会站在我的理解角度给出这几个概念的解读。另外，也会对比下业界知名的airflow。 在这之前，规则引擎是什么？ 对于一个按约定语法表达的表达式文本和事实数据，可以解析文本并用事实数据执行，得到true/false的结果。如规则表达式是：”a+b>c” ，事实数据是：{“a”:2,”b”:3,”c”:8}，那么规则引擎的返回结果应该是”false” 规则引擎库 顾名思义，它只是一个库，提供了执行表达式文本的功能。可以简单的类比成Python中的eval，其用法就是传入一串文本（使用了约定的语法的），并执行这段文本。实际上，eval要比规则引擎高级的多，它可以有各种IO,而朴素的规则引擎只能接收一串最终返回结果为bool类型的表达式文本。 作为规则引擎库，它的关注点是：1.规则可读性 2.规则执行效率 规则引擎服务 将”规则引擎库”的功能以一个服务形式提供出去。 作为规则引擎服务，它的关注点是：1.服务的稳定性 2.服务的健壮性。如果传入了不合法的文本，是否会影响服务运行 btw，有的规则引擎服务不仅限于进行true/false判断，还支持在条件为true的情况下进行kv set等基础操作 策略平台 这不是一个有严格定义的概念，只是我的朴素理解和分类。与面向开发人员的”规则引擎服务”相比，”策略平台”更像是面向普通用户的。它会额外提供一个前端页面，让用户能看到当前配置了哪些规则并添加、删除、修改规则。 实际上，在不同的业务场景下，策略平台可能会被赋予更多含义。以我在字节做的策略平台为例，相当长一段时间内，研发方向都聚焦于策略（规则及其之间关系）的表达形式。 关注点：1.平台用户友好性 2.服务稳定性 执行流引擎 以上所说的规则引擎和策略平台，都是纯计算函数，都是无外部副作用的。即不会产生对外部服务的调用，尤其是不会产生写操作。 但执行引擎与之大相径庭，执行流上每个节点都允许有外部调用。 Apache Airflow...
我的人生低谷
2年没更新博客了，工作起来太忙，后面索性都忘记自己还写过博客这件事儿了。 今天来是要吐槽。我的2021糟透了。经济上，盲目投资亏损亏损几百万，20年底暴雷，心态直接崩了。工作上，长时间地陷在一个让我失去兴趣和激情的项目中，失去了动力和很多机会。感情上，没有经济基础的情况下根本没精力顾及感情。 坦诚地说，我还没办法从经济灾难中完全恢复过来，债务压身、多年积累毁于一旦的感觉非常糟糕，因为这次暴雷和我本身的决策关系不大，所以我会常常因此而发火，无法抑制自己的情绪。为了摆脱之前的心态和无聊的项目，索性彻底地换了个轻松的工作环境，但这次转换让我意识到我并不是真正自律的人，还是很需要环境和氛围来帮助我摆脱惰性。 许个愿，2021剩下的8个月，被命运眷顾，摆脱负债。 变化永远来的比计划快，这次低潮，虽然非常负面，但也是种不一样的人生体验。人生低谷的时候，切不要给自己立太多计划和目标。因为信心是很容易气馁的，保持积极的心态第一重要。这次的教训包括：心态失衡、自我膨胀、盲目自信和他信、信息获取失效、伴侣沟通。 愿生活顺利，愿工作顺利。
DDIA-一致性与共识
精简笔记 线性一致性：单个副本的错觉 - 可序列化：事务的隔离属性，确保事务的行为与串行执行相同 - 线性一致性：读取和写入寄存器的新鲜度保证 如何做到线性一致 - 真的使用单副本。 这是必然线性一致的，但又必然没有容错能力。 - 使用多副本的话会引入复制问题。 - 单主复制。 如果主从都提供在线读，那么由于主从延迟很可能不线性一致。就算只有主提供服务，从负责热备，那么也可能有脑裂导致不线性一致。 - 多主复制。多个主节点都处理写入，很可能产生冲突从而不线性一致。 - 无主复制。使用松散的法定人数，必然不线性一致。如果使用严格的法定人数，也会因网络延迟而不线性一致。 - 共识算法。 和单主复制类似，但能防止脑裂。 线性一致的代价： - 线性一致性 VS 可用性。 多主复制是非线性一致的。那么选择了线性一致就意味着放弃了多主复制，这是在多DC部署时放弃了“可用性” - 线性一致性...
Is Kafka a Database 笔记
DDIA的作者Martin Kleppmann去年在Kafka Summit做的演讲“ Is Kafka a Database？”， 时长28分钟，视频链接 （标题吸睛，其实讲的是kafka如何实现ACID能力） 是什么让DB之所以成为DB的？ ACID ，从这个角度看 * A, all or nothing，描述的是错误处理能力。2PC 两阶段提交 能保证，但并非所有系统都能兼容2PC。 * 譬如，更新一条记录 同时到 ： web server, redis, mysql . * kafka如何做到？...