摘要：
本文主要讨论这么几个问题： （1）啥时候数据库和缓存中的数据会不一致 （2）不一致优化思路 （3）如何保证数据库与缓存的一致性 一、需求缘起 上一篇《缓存架构设计细节二三事》（点击查看）引起了广泛的讨论，其中有一个结论：当数据发生变化时，“先淘汰缓存，再修改数据库”这个点是大家讨论的最多的。 上篇文 阅读全文
摘要：
本文主要讨论四个问题： （1）为什么会有冗余表的需求 （2）如何实现冗余表 （3）正反冗余表谁先执行 （4）冗余表如何保证数据的一致性 一、需求缘起 互联网很多业务场景的数据量很大，此时数据库架构要进行水平切分，水平切分会有一个patition key，通过patition key的查询能够直接定位 阅读全文
摘要：
本文主要讨论这么几个问题： （1）“缓存与数据库”需求缘起 （2）“淘汰缓存”还是“更新缓存” （3）缓存和数据库的操作时序 （4）缓存和数据库架构简析 一、需求缘起 场景介绍 缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。 例如对于用户的余额信息表acco 阅读全文
摘要：
一、好接口的特性 易读 易用，难于误用 功能独立 容易扩展 二、好接口设计的基本原则 只做并做好一件事 函数名自解释 不恰当的函数名，往往是不恰当设计的征兆 如果没做到上一点，就将函数分解 只增加，永远不要删除函数与接口（你永远不知道这个接口被谁在使用） 实现永远不能影响接口 举例：不能假定函数调用 阅读全文
摘要：
缘起：受@萧田国 萧总邀请，上周五晚上在“高效运维1号群”内分享了《58同城数据库软件架构设计与实践》（这个topic今年在数据库大会上分享过），应组织方要求，发出纪要。 一、基本概念 二、数据库架构设计思路 （1）可用性 （2）读性能 （3）一致性 （4）扩展性 一、基本概念 概念一“单库” 概念 阅读全文
摘要：
事情变得有意思了，上一篇花1小时撰写的“一分钟”文章，又引起了广泛的讨论，说明相关的技术大家感兴趣，挺好。第一次一篇技术文章的评论量过100，才知道原来“评论精选”还有100上限，甚为欣慰（虽然是以一种自己不愿看到的方式）。 《啥，又要为表增加一列属性？》的方案颇有争议： （1）版本号version 阅读全文
摘要：
需求缘起 产品第一版：用户有用户名、密码、昵称等三个属性,对应表设计： user(uid, name, passwd, nick) 第二版，产品经理增加了年龄，性别两个属性,表结构可能要变成： user(uid, name, passwd, nick, age, sex) 假设数据量和并发量比较大， 阅读全文
摘要：
一分钟系列之《啥，又要为表增加一列属性？》分享了两种数据库属性扩展思路，被喷得厉害。第二天补充了一篇《这才是真正的表扩展方案》，分享了互联网大数据高并发情况下，数据库属性扩容的成熟工具及思路。 对于version + ext方案，还是有很多朋友质疑“线上不可能这么用”。本篇将讲述一下58同城最核心的 阅读全文
摘要：
一、什么是高可用 高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务，我们说系统的可用性是100%。 如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是9 阅读全文
摘要：
一、什么是高并发 高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。 高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per 阅读全文
