摘要：
大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。 Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。 而存 阅读全文
摘要：
总结 （1）互联网缓存最佳实践：Cache Aside Pattern （2）读实践：先缓存，命中返回，未命中读数据库，再设置缓存 （3）写实践：淘汰缓存而不是修改缓存，先操作数据库，而不是先淘汰缓存 阅读全文
摘要：
总结，进程内缓存 （1）服务与服务之间不要通过缓存传递数据 （2）如果缓存挂掉，可能导致雪崩，此时要做高可用缓存，或者水平切分 （2）调用方不宜再单独使用缓存存储服务底层的数据，容易出现数据不一致，以及反向依赖 （2）不同服务，缓存实例要做垂直拆分，不宜共用缓存 阅读全文
摘要：
总结，进程内缓存 优点： （1）节省内网带宽 （2）时延更低 不足：一致性难以保证 什么场景适用？ （1）只读数据 （2）并发极高，透传后端压力极大 （3）允许一定程序上数据不一致 保证一致性的方法？ （1）单节点通知其他节点 （2）MQ解耦，通知其他节点 （3）放弃实时一致性，定期从后端更新数据 阅读全文
摘要：
总结，数据库水平切分，秒级成倍扩容 互联网大数据量，高吞吐量，高可用微服务分层架构 数据库实现秒级平滑扩容的三个步骤为： （1）修改配置（双虚ip，微服务数据库路由）； （2）reload配置，实例增倍完成； （3）删除冗余数据等收尾工作，数据量减半完成； 阅读全文
摘要：
总结，追日志方案 VS 双写方案 追日志方案： 追日志方案： （1）服务升级，记录“数据修改”的日志； （1）服务升级，“数据修改”双写； （2）迁移数据小工具，进行数据迁移； （2）迁移数据小工具，进行数据迁移； （3）追日志小工具，追平数据库差异； （3）追日志小工具，追平数据库差异； （4）数 阅读全文
摘要：
总结 扩展性，解决什么问题? （1）底层表结构变更 （2）水平扩展，分库个数变化 （3）底层存储介质变化 方案一，停服扩展（离线，非高可用） （1）挂公告，暂停服务 （2）离线迁移数据 （3）恢复服务 方案二，pt-online-schema-change（平滑） 方案三，追日志方案（平滑） （1） 阅读全文
摘要：
总结 主从数据冗余，主从不一致： （1）忽略 （2）强制读主 （3）借助缓存，选择性读主 主主数据冗余，主主不一致： （1）数据库不同初始值，相同增长步长 （2）应用层生成不同冲突ID （3）一个主库提供服务 数据库工程架构设计，必须考虑什么： （1）读性能提升 （2）高可用 （3）一致性保障 （4 阅读全文
摘要：
总结 垂直拆分？尽量把： （1）长度较短 （2）访问频率较高 （3）经常一起访问 的属性放在主表里； 原因：数据库缓冲池，逻辑上，以row为单位缓冲数据。 举个例子，假设缓冲池1G Case1，未拆分： user表，1行记录为1k，只能缓存100w行数据 Case2，垂直拆分： user_base表 阅读全文
摘要：
总结 数据库要设计什么： （1）依据“业务模式”设计表结构 （2）依据“访问模式”设计索引结构 读性能提升，常见方法与实践： （1）增加索引，不同实例不同索引 缺点：① 写性能降低 ②索引占用内存大，buffer命中率降低，读性能降低 实例：用户中心功能实施一主两从，读写分离架构。 其中主库只为线上 阅读全文