摘要：
第一章聊了【“为什么要进行服务化，服务化究竟解决什么问题”】 第二章聊了【“微服务的服务粒度选型”】 第三章聊了【“为什么说要搞定微服务架构，先搞定RPC框架？”】 上一章聊了【“微服务架构之RPC-client序列化细节”】 通过上篇文章的介绍，知道了要实施微服务，首先要搞定RPC框架，RPC框架 阅读全文
摘要：
第一章聊了【“为什么要进行服务化，服务化究竟解决什么问题”】 第二章聊了【“微服务的服务粒度选型”】 上一篇聊了【“为什么说要搞定微服务架构，先搞定RPC框架？”】 通过上篇文章的介绍，知道了要实施微服务，首先要搞定RPC框架，RPC框架的职责要向【调用方】和【服务提供方】屏蔽各种复杂性： （1）让 阅读全文
摘要：
第一章聊了【“为什么要进行服务化，服务化究竟解决什么问题”】 第二章聊了【“微服务的服务粒度选型”】 今天开始聊一些微服务的实践，第一块，RPC框架的原理及实践，为什么说要搞定微服务架构，先搞定RPC框架呢？ 一、需求缘起 服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团 阅读全文
摘要：
一、缘起 （1）并发量大，流量大的互联网架构，一般来说，数据库上层都有一个服务层，服务层记录了“业务库名”与“数据库实例”的映射关系，通过数据库连接池向数据库路由sql语句以执行： 如上图：服务层配置用户库user对应的数据库实例物理位置为ip（其实是一个内网域名）。 （2）随着数据量的增大，数据要 阅读全文
摘要：
一、缘起 当数据库的数据量非常大时，水平切分和垂直拆分是两种常见的降低数据库大小，提升性能的方法。假设有用户表： user( uid bigint, name varchar(16), pass varchar(16), age int, sex tinyint, flag tinyint, sig 阅读全文
摘要：
可能每个人都无意删除过根目录，我的case是这样的，执行了一个清理日志的脚本，大致的逻辑是： ... cd ${log_path} rm -rf * ... 看上去没有任何问题，进入到日志目录，然后把日志都删除。 但是，当目录不存在时，悲剧就发生了。 程序员总是会这么自信，认为自己写的代码是完美的， 阅读全文
摘要：
缘起：有个朋友问我分区表在58的应用，我回答不出来，在我印象中，百度、58都没有听说有分区表相关的应用，业内进行一些技术交流的时候也更多的是自己分库分表，而不是使用分区表。于是去网上查了一下，并询问了58到家的DBA专家，将自己收到的信息沉淀下来，share给大伙。 解决什么问题？ 回答：当mysq 阅读全文
摘要：
一、缘起 mysql主从复制，读写分离是互联网用的非常多的mysql架构，主从复制最令人诟病的地方就是，在数据量较大并发量较大的场景下，主从延时会比较严重。 为什么mysql主从延时这么大？ 回答：从库使用【单线程】重放relaylog。 优化思路是什么？ 回答：使用单线程重放relaylog使得同 阅读全文
摘要：
前情提要：互联网架构为什么要做服务化？ 一、互联网架构为什么要进行服务化-总结 上一篇和大伙交流了一下，随着数据量、并发量、业务复杂度的增长，互联网架构会出现以下问题： （1）代码到处拷贝 （2）底层复杂性扩散 （3）基础库（so/jar/dll）耦合 （4）SQL质量得不到保障，业务相互影响 （5 阅读全文
摘要：
一、案例缘起 我们经常使用事务来保证数据库层面数据的ACID特性。 举个栗子，用户下了一个订单，需要修改余额表，订单表，流水表，于是会有类似的伪代码： start transaction; CURDtable t_account; any Exception rollback; CURDtable 阅读全文
摘要：
近期参加一些业界的技术大会，“微服务架构”的话题非常之火，也在一些场合聊过服务化架构实践，最近几期文章期望用通俗易懂的语言聊聊了个人对服务化以及微服务架构的理解，希望能给大伙一些启示。如果有遗漏，也欢迎大家补充。 一、互联网高可用架构，为什么要服务化？ 【服务化之前高可用架构】 在服务化之前，互联网 阅读全文
摘要：
需求缘起 大部分互联网的业务都是“读多写少”的场景，数据库层面，读性能往往成为瓶颈。如下图：业界通常采用“一主多从，读写分离，冗余多个读库”的数据库架构来提升数据库的读性能。 这种架构的一个潜在缺点是，业务方有可能读取到并不是最新的旧数据： （1）系统先对DB-master进行了一个写操作，写主库 阅读全文
摘要：
本文主要讨论这么几个问题： （1）数据库主从延时为何会导致缓存数据不一致 （2）优化思路与方案 一、需求缘起 上一篇《缓存架构设计细节二三事》中有一个小优化点，在只有主库时，通过“串行化”的思路可以解决缓存与数据库中数据不一致。引发大家热烈讨论的点是“在主从同步，读写分离的数据库架构下，有可能出现脏 阅读全文
摘要：
本文主要讨论这么几个问题： （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) 假设数据量和并发量比较大， 阅读全文