电商业务架构背后的Know-Why:关于一致性的思考和Best Practise
各种一致性模型和选型决策树
各种一致性模型和选型决策树
业务的后台开发,过去的工作出彩点很多时候是:在完成业务需求的同时,弥补基础设施的不足。在近几年,随着底层 PaaS 的日益完善,这类的短板在变少:比如好几年前的数据库分库分表,可能需要一个中间件团队的几个 DBA 专门开发和维护。但现在很多云厂商的数据库,天然就是分片和主备容灾的。这是技术的复利效应,也是所有业务...
除了goroutine之外,channel 是 golang 中最核心的 feature 之一,因此理解 Channel 的原理对于学习和使用 golang 也很重要。
最近工作用到Golang会比较多。因此计划花2 - 3星期学学Go语言。在这里记录学习过程的一些记录和想法。希望对你也有帮助。
很多的业务系统都是“干”出来的,意思是产品确定了需求后,开发设计下表层面的数据结构,然后写一系列面向数据库增删改查的接口,通过测试后上线。这种模式在一些项目周期短或者不确定性很大场景下是可行的。但项目很快会暴露问题:代码快速腐化,持续迭代的能力快速下降。从项目开始开发到不可维护的周期,我见过最短的是7-8个月。
在分布式系统或单机系统中,对数据的处理分别有两种常见手段,是批处理(batch processing)和流处理(stream processing)。 区别于流处理,批处理的手段处理数据会有这几个特点和隐含的假设: 处理过程中,不能和终端用户交互(区别于交互式的处理) 数据量大,而且是冷数据,或称离线数...
在分布式系统中,时刻要想着design for failure。接口调用失败(非业务异常)和超时是最常见的一种错误(fault),而幂等的设计是针对此类问题的容错手段。
再来看看java的juc包下的线程池相关实现。既然面试那么那么爱考,那就把它背一背。
atomic包是juc下的其中一个包,主要是封装常用变量,方便使用者可以原子操作。
分布式锁的原始用法是:使集群内所有线程互斥地执行某一个方法:
最近的项目深度使用redis,需要好好调研一下。这篇文章会做些笔记
在分布式系统里,每时每刻都有组件出现故障。分布式系统的特点在于:build a reliable system from unreliable components。在看怎么容错之前,先看看有哪些可能出现的故障(fault)。
单机事务(本文会简称为事务),区分于分布式事务,可以大致这样定义:单机事务的场景里,客户端可以有多个,但提供写入操作的节点只有一个,单机就是提供写入的服务器的单机。事务是数据库提供的最强大的保证:单机事务中,最复杂的是并发问题,随时有可能出现多个client同时修改同一个记录的情况,而正是利用不同的事务的隔离级别...
上一篇文章说了分布式系统的复制(replication)技术。这一篇来说说分区(partitioning)。