Non-blocking Synchronization

Non-blocking Synchronization 1. Wait-free  Wait-free 是指任意线程的任何操作都可以在有限步之内结束,而不用关心其它线程的执行速度。 Wait-free 是基于 per-thread 的,可以认为是 starvation-free 的。非常遗憾的是实际情况并非如此,采用 Wait-free 的程序并不能保证 starvation-free,同时内存消耗也随线程数量而线性增长。目前只有极少数的非阻塞算法实现了这一点。  2. Lock-free  Lock-Free 是指能够确保执行它的所有线程中至少有一个能够继续往下执行。由于每个线程不是 starvation-free 的,即有些线程可能会被任意地延迟,然而在每一步都至少有一个线程能够往下执行,因此系统作为一个整体是在持续执行的,可以认为是 system-wide 的。所有 Wait-free 的算法都是 Lock-Free 的。  3. Obstruction-free  Obstruction-free 是指在任何时间点,一个孤立运行线程的每一个操作可以在有限步之内结束。只要没有竞争,线程就可以持续运行。一旦共享数据被修改,Obstruction-free 要求中止已经完成的部分操作,并进行回滚。所有 Lock-Free 的算法都是 Obstruction-free 的。  综上所述,不难得出 Obstruction-free 是 Non-blocking synchronization 中性能最差的,而 Wait-free 性能是最好的,但实现难度也是最大的,因此 Lock-free 算法开始被重视,并广泛运用于当今正在运行的程序中,比如linux内核。  一般采用原子级的 read-modify-write 原语来实现 Lock-Free 算法,其中 LL 和 SC 是 Lock-Free 理论研究领域的理想原语,但实现这些原语需要 CPU 指令的支持,非常遗憾的是目前没有任何 CPU 直接实现了 SC 原语。根据此理论,业界在原子操作的基础上提出了著名的 CAS(Compare - And - Swap)操作来实现 Lock-Free 算法,Intel 实现了一条类似该操作的指令:cmpxchg8。

1 minute read

Mysql优化

三板斧 慢查询日志 分场景开启,一般在自测,内测前开启 生产环境不建议开启 explain执行计划 show profile 表与索引的存储方式 B+Tree,高度及广度带来的问题。这个单独写篇文章进行描述。 索引 大多数情况,一个简单的sql只能用到一个索引 简单:不包含子查询或者JOIN的sql mysql内部进行索引带价计算,选择区分度大的索引,和SQL里面and的顺序无关 建立合适的索引 Index...

5 minute read

架构概览

先放着大纲,趁宅在家,慢慢写 这个架构图能覆盖大多数互联网公司的技术点: 存储层 SQL 一般情况下互联网行业都是用 MySQL、PostgreSQL 这类开源数据库。 这类数据库的特点是开源免费,拿来就用;但缺点是性能相比商业数据库要差一些。 但随着性能要求越来越高,分表拆库多实例是必然的方向,包括Oracle也是,只是时间早晚的事。 但分表拆库多实例带来复杂度的问题:数据如何拆分、数据如何组合?这个复杂度的问题解决起来并不容易,如果每个业务都去实现一遍,重复造轮子将导致投入浪费、效率降低,业务开发想快都快不起来。 所以互联网公司流行的做法是业务发展到一定阶段后,就会将这部分功能独立成中间件。例如百度的 DBProxy、淘宝的 TDDL。 将分库分表做到自动化和平台化,一般是规模很大的公司才会自己做。 中小公司建议使用开源方案,例如...

2 minute read

微服务

先放着大纲,趁宅在家,慢慢写. 缺一个树状导图。 发布和引用服务 服务提供者如何发布一个服务,服务消费者如何引用这个服务。 最常见的服务发布和引用的方式有三种: RESTful API 可参考开源服务化框架Motan发布 RESTful API 的例子 XML 配置 XML 配置这种方式的服务发布和引用主要分三个步骤:...

4 minute read

基于FMEA排除架构可用性隐患

高可用在一般情况下相对于高性能更复杂一些,主要原因在于异常的场景很多,只要有一个场景遗漏,架构设计就存在可用性隐患 什么是FMEA FMEA(Failure mode and effects analysis,故障模式与影响分析) FMEA 是一种在各行各业都有广泛应用的可用性分析方法, 通过对系统范围内潜在的故障模式加以分析,并按照严重程度进行分类,以确定失效对于系统的最终影响。 回到软件架构设计领域,FMEA 并不能指导我们如何做架构设计,而是当我们设计出一个架构后, 再使用 FMEA 对这个架构进行分析,看看架构是否还存在某些可用性的隐患。...

1 minute read

能力下沉

能力下沉 一般来说实践DDD有两个过程: ★ 套概念阶段:了解了一些DDD的概念, 然后在代码中“使用”Aggregation Root,Bounded Context,Repository等等这些概念。 更进一步,也会使用一定的分层策略。 然而这种做法一般对复杂度的治理并没有多大作用。 ★ 融会贯通阶段:术语已经不再重要,理解DDD的本质是统一语言、边界划分和面向对象分析的方法。 大体上而言,我大概是在1.7的阶段,因为有一个问题一直在困扰我, 就是哪些能力应该放在Domain层,是不是按照传统的做法,将所有的业务都收拢到Domain上, 这样做合理吗?说实话,这个问题我一直没有想清楚。 因为在现实业务中,很多的功能都是用例特有的(Use...

1 minute read

近四年来的总结

来当前的公司已经近四年了,部门产品从0到1,公司从上市到退市,不少感触容我慢慢回忆。 回忆以产品技术发展为主,顺便聊聊产品及管理的理解。 ps:因为迁移blog,所以很多内容并没有很好的转过来,之前使用adoc+hugo发布我的blog。 2016 年 熟悉行业,重构现有产品,构建雏形 4月份加入该公司,负责公司的新产品线E-Navigation,原来的产品为电子海图。单从 E-Navigation 的概念上来说,就是一盘非常大的棋。 e-Navigation is about using modern technology...

1 minute read

架构设计流程

识别复杂度 将主要的复杂度问题列出来, 然后根据业务、技术、团队等综合情况进行排序,优先解决当前面临的最主要的复杂度问题 对于按照复杂度优先级解决的方式,存在一个普遍的担忧:如果按照优先级来解决复杂度,可能会出现解决了优先级排在前面的复杂度后,解决后续复杂度的方案需要将已经落地的方案推倒重来。 这个担忧理论上是可能的,但现实中几乎是不可能出现的,原因在于软件系统的可塑性和易变性。 对于同一个复杂度问题,软件系统的方案可以有多个,总是可以挑出综合来看性价比最高的方案。 即使决定要推倒重来,这个新的方案也必须能够同时解决已经被解决的复杂度问题, 一般来说能够达到这种理想状态的方案基本都是依靠新技术的引入。 例如:Hadoop 能够将高可用、高性能、大容量三个大数据处理的复杂度问题同时解决。 关键指标 “高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标,也可以从用户的主观感受方面去考虑。 对于常见中间件的性能量级范围: nginx负载均衡性能是3万左右,mc的读取性能5万左右,kafka号称百万级, zookeeper写入读取2万以上,http请求访问大概在2万左右。...

1 minute read