获得徽章 0
- #每天一个知识点# 面对神出鬼没的并发 Bug 怎么办?
我们知道,一个运行在真实世界上的分布式系统充满了各种各样的不确定性:多个节点之间,网络上的通信可能导致消息被延迟、丢失或者乱序;一个节点内部,多个线程的执行顺序无法预测,受到操作系统调度的影响;甚至一个线程内部,也会由于随机数的存在,导致每次运行都会产生不一样的结果。而某些并发问题,恰恰只在某种特定的执行顺序下才会出现。
面对这一问题,学术界和工业界都提出过不同的解决方案。
学界的主要思路倾向于形式化验证,或者对所有可能状态进行穷举,以证明系统 100% 正确。例如常用于证明分布式算法正确性的 TLA+ 语言,以及 Rust tokio 社区实现的验证并发正确性的 loom 框架。但是这种方法的局限性在于只适用于算法或小型系统,任何规模稍大的实际系统都会面临组合爆炸的问题,从而无法被有效验证。
工业界对此的解决方案倾向于通过大量测试覆盖尽可能多的可能性,其中比较知名的技术是混沌工程(Chaos Engineering)。混沌工程通过主动向系统中注入错误和随机性,使环境变得更加混乱,从而提高 Bug 出现的概率。例如攻破过无数分布式数据库的 Jepsen 框架,以及用于云原生系统的 Chaos Mesh 平台。这种方案可以有效验证实际系统在真实环境下的行为,但是有一点遗憾,那就是它们依然无法控制不确定性。发现了问题但无法保证 100% 的复现,这对开发调试依然是不友好的。
确定性模拟是消除系统中不确定性的绝佳技术,大家如果感兴趣可以下面查看这篇专栏,文章细致介绍了确定性模拟产生的背景、基本原理、测试框架的设计,以及我们在 RisingWave 中应用确定性测试的方法和经验。展开评论点赞 - #每天一个知识点# 每天一个知识点|确定性模拟:排除系统潜在问题的绝佳测试技术
确定性模拟(Deterministic Simulation)是一种独特的系统测试技术,它可以将整个分布式系统的各个组件运行在一个单线程模拟器上,从而实现系统的确定性执行。
这一技术的最大好处在于能够稳定地复现那些可能运行上千次才出现一次的 bug,并且运行速度非常快,能够在短时间内模拟现实中很长时间的行为。
有了这一工具,我们就可以在有限的时间内尽可能多的测试系统在不同环境下的行为。而一旦发现了问题,也可以非常从容地去排查和除错。这一技术曾经被应用在分布式 KV 数据库 FoundationDB 中,对提高该系统的稳定性与可靠性作出了不可磨灭的贡献。
如果大家对确定性模拟感兴趣的话,动动小手点赞,我们将发文介绍确定性模拟产生的背景、基本原理、测试框架的设计,以及我们在 RisingWave 中应用确定性测试的方法和经验。
图 2 为基于 Rust 异步编程生态实现的分布式系统确定性模拟器“madsim 测试框架”的内部结构。展开赞过评论2 - #每日快讯# 为什么各大 VC 最近都在投向量数据库?
最近几个月资本疯狂涌入向量数据库赛道,赛道梯队也逐渐成型。估值在一亿美金内的有 Chroma 和 Qdrant,总融资金额在千万美金级别;估值在五亿美金内的有 Weaviate,总融资金额在 5000 万美金级别;估值在五亿美金之上的有两家公司 Pinecone 和 Zilliz,总融资金额都超过了一亿美金。
其实原因也很简单:从目前 VC 的投资数据来看,大家对 AI 的关注点主要有三个:一个是基础大模型 LLM,第二个是具体某个场景的应用(包括小模型),第三个就属基础模型与应用层之间的中间层了(开发者工具和数据库等)。
随着开发者疯狂涌入开发各种 AI 应用,中间层已经成为各大 VC 争抢的投资标的,作为 AI 时代 Memory 的向量数据库,自然成为了大热门。展开评论点赞 - #挑战每日一条沸点# 又帅又幽默又有才华的 JY 们,自荐一个专为流处理设计的分布式 SQL 数据库项目:RisingWave。
它兼容 PostgreSQL 协议,不依赖于一系列基于JVM 的复杂组件,让用户能够以极低的门槛学习、开发和运维流处理系统。同时,使用 Rust 开发,RisingWave 通过存算分离架构、分层存储以及对 SQL 语言的高度定制化优化,实现了卓越的性能提升。根据标准的 Nexmark 基准测试,与 Apache Flink 相比,RisingWave 在无状态计算方面可以获得 10-30% 的性能提升;而在有状态计算方面,性能提升至多可达 660 倍。
欢迎感兴趣的 JY 们了解。(摸鱼快乐
) 展开评论点赞 - #每天一个知识点# Nginx 是 C 语言写的,为啥从来不会挂掉?
1、结构设计非常合理。
2、编码技术过硬。
3、这么多年来,能被发现的 bug 早就被修掉了,也就是久经历练。
从设计到部署层面,都做了很多风险隔离:
1、主进程非常简单,简单到明显没有 bug。
2、杂活都丢给 worker,一个 worker 一个进程,挂一个不会影响其他,重新拉起来就行,不扩散影响。
3、在系统层面可以选择用其他工具监控主进程,异常退出就重启。
这么三把斧下来,应用层面能被观测到的宕机就少之又少了。从另外一个意义上,“稳定”靠的是机制上具备风险隔离和自救能力,而这些和用什么语言,无关……如果非要说有关系的话,那就是,越底层的语言,可控制度越高,如果用其他语言(例如 Python、Lua),则需要再考虑 VM 本身的稳健性。展开等人赞过24
)