摘要：
一、缘起 （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）优化思路与方案 一、需求缘起 上一篇《缓存架构设计细节二三事》中有一个小优化点，在只有主库时，通过“串行化”的思路可以解决缓存与数据库中数据不一致。引发大家热烈讨论的点是“在主从同步，读写分离的数据库架构下，有可能出现脏 阅读全文
