电商业务架构背后的Know-Why:关于一致性的思考和Best Practise
各种一致性模型和选型决策树
各种一致性模型和选型决策树
业务的后台开发,过去的工作出彩点很多时候是:在完成业务需求的同时,弥补基础设施的不足。在近几年,随着底层 PaaS 的日益完善,这类的短板在变少:比如好几年前的数据库分库分表,可能需要一个中间件团队的几个 DBA 专门开发和维护。但现在很多云厂商的数据库,天然就是分片和主备容灾的。这是技术的复利效应,也是所有业务...
atomic包是juc下的其中一个包,主要是封装常用变量,方便使用者可以原子操作。
在分布式系统或单机系统中,对数据的处理分别有两种常见手段,是批处理(batch processing)和流处理(stream processing)。 区别于流处理,批处理的手段处理数据会有这几个特点和隐含的假设: 处理过程中,不能和终端用户交互(区别于交互式的处理) 数据量大,而且是冷数据,或称离线数...
除了goroutine之外,channel 是 golang 中最核心的 feature 之一,因此理解 Channel 的原理对于学习和使用 golang 也很重要。
最近工作用到Golang会比较多。因此计划花2 - 3星期学学Go语言。在这里记录学习过程的一些记录和想法。希望对你也有帮助。
最近有机会一个人负责、主导一个项目。其中一项工作,就是需要从零开始写代码做一个code project。在整个过程中,我一直在学习和思考怎么写可维护的代码,写一个可以 一直维护,一直迭代,却把复杂度控制在一定的范围之内 的项目。
领域事件是DDD里的一个概念。牛逼的领域专家觉得:
再来看看java的juc包下的线程池相关实现。既然面试那么那么爱考,那就把它背一背。
atomic包是juc下的其中一个包,主要是封装常用变量,方便使用者可以原子操作。
在分布式系统中,节点需要协作,同步。在多线程程序中,线程之间也需要协作,同步:一个线程进入某个方法之前可能需要等其他的某个线程执行完某个方法之后。我们使用锁来协调这些线程间同步。
java.util.concurrent包提供了多线程编程相关的工具接口,主要有:Executor、ExecutorService、Future等。
学习一下java并发编程常用到的包:java.util.concurrent。先来看下overview。
除了goroutine之外,channel 是 golang 中最核心的 feature 之一,因此理解 Channel 的原理对于学习和使用 golang 也很重要。
最近工作用到Golang会比较多。因此计划花2 - 3星期学学Go语言。在这里记录学习过程的一些记录和想法。希望对你也有帮助。
各种一致性模型和选型决策树
最近的项目深度使用redis,需要好好调研一下。这篇文章会做些笔记
很多的业务系统都是“干”出来的,意思是产品确定了需求后,开发设计下表层面的数据结构,然后写一系列面向数据库增删改查的接口,通过测试后上线。这种模式在一些项目周期短或者不确定性很大场景下是可行的。但项目很快会暴露问题:代码快速腐化,持续迭代的能力快速下降。从项目开始开发到不可维护的周期,我见过最短的是7-8个月。
最近有机会一个人负责、主导一个项目。其中一项工作,就是需要从零开始写代码做一个code project。在整个过程中,我一直在学习和思考怎么写可维护的代码,写一个可以 一直维护,一直迭代,却把复杂度控制在一定的范围之内 的项目。
领域事件是DDD里的一个概念。牛逼的领域专家觉得:
分布式锁的原始用法是:使集群内所有线程互斥地执行某一个方法:
在分布式系统或单机系统中,对数据的处理分别有两种常见手段,是批处理(batch processing)和流处理(stream processing)。 区别于流处理,批处理的手段处理数据会有这几个特点和隐含的假设: 处理过程中,不能和终端用户交互(区别于交互式的处理) 数据量大,而且是冷数据,或称离线数...
在分布式系统中,时刻要想着design for failure。接口调用失败(非业务异常)和超时是最常见的一种错误(fault),而幂等的设计是针对此类问题的容错手段。
分布式锁的原始用法是:使集群内所有线程互斥地执行某一个方法:
在分布式系统里,每时每刻都有组件出现故障。分布式系统的特点在于:build a reliable system from unreliable components。在看怎么容错之前,先看看有哪些可能出现的故障(fault)。
单机事务(本文会简称为事务),区分于分布式事务,可以大致这样定义:单机事务的场景里,客户端可以有多个,但提供写入操作的节点只有一个,单机就是提供写入的服务器的单机。事务是数据库提供的最强大的保证:单机事务中,最复杂的是并发问题,随时有可能出现多个client同时修改同一个记录的情况,而正是利用不同的事务的隔离级别...
上一篇文章说了分布式系统的复制(replication)技术。这一篇来说说分区(partitioning)。
经常有一些面试题喜欢让人设计一个分布式存储系统,其目的是面试者对分布式系统的常见知识的掌握和运用。这篇文章来讨论下这个问题,从redis的实现说起,看看一个分布式系统高可用的方案有哪些。
异地多活(multi-datacenter)是饿厂在16年立项,17年完成的重大技术项目。众所周知,多活的技术挑战相当大,是分布式系统技术设计的高峰。实施过程几乎动员所有技术同学。有幸,作为一个业务开发,参与了后半部(实施部分)。虽然有过项目经验的同学都知道,一个项目最大的挑战和有意思的部分,都是在前期讨论的时期...
在看一本很棒的书,《Designing Data-Intensive Applications》。可以说是很多分布式问题的导论了。接下来会有一系列的文章结合书中内容,说说我的归纳、总结和一些思考。由于是一本关于分布式数据库的书,所以里面很多例子会以数据库领域遇到的问题作为引子,但是大部分分布式系统要解决的问题都是...
google file system是15年前(2003)google发布的一个分布式文件系统论文,这篇论文可以说是分布式系统的入门经典。google应该是全球最早遇到如此复杂的分布式技术难题的公司。gfs是其中一个难题的解决方案:超大规模的,可靠的文件存储。看gfs的这篇论文,可以看到google的牛逼的大神们...
降级和熔断,和限流一样,都可以说属于服务化中流量调控的范畴。主要目的都是一样的:防止大流量冲垮整个集群。
顺着上一篇文章的思路,服务路由一般是这么做的:有一个服务注册中心,它知道网络内所有节点的情况,暴露restful接口(甚至是长连接)给各个消费方消费。
为什么需要服务路由和负载均衡
前文已经说过限流的概念和用法。理解起来或用起来都没什么高深的,最终目的都是限制并发,控制流量。本文主要讲一下它的几种实现和要解决的问题。
这系列文章会系统的说说一些服务治理的技术点,例如:限流、降级、熔断、隔离、路由 & 负载均衡、服务注册 & 发现 等等。又由于作者还没对分布式系统有啥全局的把握,所以只能逐点逐点的学习分析,对于已经掌握的,就暂时不再重复总结了。
很多的业务系统都是“干”出来的,意思是产品确定了需求后,开发设计下表层面的数据结构,然后写一系列面向数据库增删改查的接口,通过测试后上线。这种模式在一些项目周期短或者不确定性很大场景下是可行的。但项目很快会暴露问题:代码快速腐化,持续迭代的能力快速下降。从项目开始开发到不可维护的周期,我见过最短的是7-8个月。
各种一致性模型和选型决策树
业务的后台开发,过去的工作出彩点很多时候是:在完成业务需求的同时,弥补基础设施的不足。在近几年,随着底层 PaaS 的日益完善,这类的短板在变少:比如好几年前的数据库分库分表,可能需要一个中间件团队的几个 DBA 专门开发和维护。但现在很多云厂商的数据库,天然就是分片和主备容灾的。这是技术的复利效应,也是所有业务...
再来看看java的juc包下的线程池相关实现。既然面试那么那么爱考,那就把它背一背。
在分布式系统里,每时每刻都有组件出现故障。分布式系统的特点在于:build a reliable system from unreliable components。在看怎么容错之前,先看看有哪些可能出现的故障(fault)。
在分布式系统里,每时每刻都有组件出现故障。分布式系统的特点在于:build a reliable system from unreliable components。在看怎么容错之前,先看看有哪些可能出现的故障(fault)。
除了goroutine之外,channel 是 golang 中最核心的 feature 之一,因此理解 Channel 的原理对于学习和使用 golang 也很重要。
最近工作用到Golang会比较多。因此计划花2 - 3星期学学Go语言。在这里记录学习过程的一些记录和想法。希望对你也有帮助。
除了goroutine之外,channel 是 golang 中最核心的 feature 之一,因此理解 Channel 的原理对于学习和使用 golang 也很重要。
最近工作用到Golang会比较多。因此计划花2 - 3星期学学Go语言。在这里记录学习过程的一些记录和想法。希望对你也有帮助。
除了goroutine之外,channel 是 golang 中最核心的 feature 之一,因此理解 Channel 的原理对于学习和使用 golang 也很重要。
最近工作用到Golang会比较多。因此计划花2 - 3星期学学Go语言。在这里记录学习过程的一些记录和想法。希望对你也有帮助。
在分布式系统中,时刻要想着design for failure。接口调用失败(非业务异常)和超时是最常见的一种错误(fault),而幂等的设计是针对此类问题的容错手段。
再来看看java的juc包下的线程池相关实现。既然面试那么那么爱考,那就把它背一背。
atomic包是juc下的其中一个包,主要是封装常用变量,方便使用者可以原子操作。
在分布式系统中,节点需要协作,同步。在多线程程序中,线程之间也需要协作,同步:一个线程进入某个方法之前可能需要等其他的某个线程执行完某个方法之后。我们使用锁来协调这些线程间同步。
java.util.concurrent包提供了多线程编程相关的工具接口,主要有:Executor、ExecutorService、Future等。
学习一下java并发编程常用到的包:java.util.concurrent。先来看下overview。
再来看看java的juc包下的线程池相关实现。既然面试那么那么爱考,那就把它背一背。
atomic包是juc下的其中一个包,主要是封装常用变量,方便使用者可以原子操作。
在分布式系统中,节点需要协作,同步。在多线程程序中,线程之间也需要协作,同步:一个线程进入某个方法之前可能需要等其他的某个线程执行完某个方法之后。我们使用锁来协调这些线程间同步。
java.util.concurrent包提供了多线程编程相关的工具接口,主要有:Executor、ExecutorService、Future等。
学习一下java并发编程常用到的包:java.util.concurrent。先来看下overview。
上一篇说完GC收集器,这一篇科普一下另一项基本技能,同时也是排查问题的时候经常需要的:分析GC Log。
上一篇讲了一系列的GC算法。这一篇来看看这些算法的具体实现,也就是GC收集器。
第一篇说完了JVM运行时的内存分区。这一篇说说GC的一些基本知识。GC是JVM层面的垃圾回收机制,它不由程序员控制。我们可以问:GC是什么时候对什么东西做了什么事?下文会从这个思路去行文。
前几天线上出了个JVM方面的问题,看来有必要对JVM的知识再梳理和复习一下。(本系列会以JVM 8为例分析)
上一篇说完GC收集器,这一篇科普一下另一项基本技能,同时也是排查问题的时候经常需要的:分析GC Log。
上一篇讲了一系列的GC算法。这一篇来看看这些算法的具体实现,也就是GC收集器。
第一篇说完了JVM运行时的内存分区。这一篇说说GC的一些基本知识。GC是JVM层面的垃圾回收机制,它不由程序员控制。我们可以问:GC是什么时候对什么东西做了什么事?下文会从这个思路去行文。
前几天线上出了个JVM方面的问题,看来有必要对JVM的知识再梳理和复习一下。(本系列会以JVM 8为例分析)
在分布式系统或单机系统中,对数据的处理分别有两种常见手段,是批处理(batch processing)和流处理(stream processing)。 区别于流处理,批处理的手段处理数据会有这几个特点和隐含的假设: 处理过程中,不能和终端用户交互(区别于交互式的处理) 数据量大,而且是冷数据,或称离线数...
异地多活(multi-datacenter)是饿厂在16年立项,17年完成的重大技术项目。众所周知,多活的技术挑战相当大,是分布式系统技术设计的高峰。实施过程几乎动员所有技术同学。有幸,作为一个业务开发,参与了后半部(实施部分)。虽然有过项目经验的同学都知道,一个项目最大的挑战和有意思的部分,都是在前期讨论的时期...
各种一致性模型和选型决策树
业务的后台开发,过去的工作出彩点很多时候是:在完成业务需求的同时,弥补基础设施的不足。在近几年,随着底层 PaaS 的日益完善,这类的短板在变少:比如好几年前的数据库分库分表,可能需要一个中间件团队的几个 DBA 专门开发和维护。但现在很多云厂商的数据库,天然就是分片和主备容灾的。这是技术的复利效应,也是所有业务...
除了goroutine之外,channel 是 golang 中最核心的 feature 之一,因此理解 Channel 的原理对于学习和使用 golang 也很重要。
最近工作用到Golang会比较多。因此计划花2 - 3星期学学Go语言。在这里记录学习过程的一些记录和想法。希望对你也有帮助。
前两天线上出了个CPU使用率飙升的问题。虽然最后是排查出来的,但排查时间太长了,思路还是有待提高。排查过程中用到非常多的JVM知识,一些是原来就会的,一些是边搞边学的(这就是慢的原因)。记录一下,下次遇到类似情况,整个时长应该可以缩短80%。
前几天出现了一个线上故障,将排查过程和验尸报告记录一下。
分布式锁的原始用法是:使集群内所有线程互斥地执行某一个方法:
最近的项目深度使用redis,需要好好调研一下。这篇文章会做些笔记
经常有一些面试题喜欢让人设计一个分布式存储系统,其目的是面试者对分布式系统的常见知识的掌握和运用。这篇文章来讨论下这个问题,从redis的实现说起,看看一个分布式系统高可用的方案有哪些。
很多的业务系统都是“干”出来的,意思是产品确定了需求后,开发设计下表层面的数据结构,然后写一系列面向数据库增删改查的接口,通过测试后上线。这种模式在一些项目周期短或者不确定性很大场景下是可行的。但项目很快会暴露问题:代码快速腐化,持续迭代的能力快速下降。从项目开始开发到不可维护的周期,我见过最短的是7-8个月。
单机事务(本文会简称为事务),区分于分布式事务,可以大致这样定义:单机事务的场景里,客户端可以有多个,但提供写入操作的节点只有一个,单机就是提供写入的服务器的单机。事务是数据库提供的最强大的保证:单机事务中,最复杂的是并发问题,随时有可能出现多个client同时修改同一个记录的情况,而正是利用不同的事务的隔离级别...