坤妹家萌萌哒萌新

摘要： 总结 （1）数据库主从，何时不一致？写后立即读，短时间内，读旧数据 （2）数据库缓存，何时不一致？写后立即读，短时间内，旧数据入缓存 （3）优化思路：如果有旧数据入缓存，应该及时把这个旧数据淘汰掉 （4）优化方法： - 二次淘汰法（异步，服务） - 设定超时时间，有机会修正 阅读全文

摘要： MySQL中有以下日志文件，分别是： 1：重做日志（redo log） 2：回滚日志（undo log） 3：二进制日志（binlog） 4：错误日志（errorlog） 5：慢查询日志（slow query log） 6：一般查询日志（general log） 7：中继日志（relay log）。 阅读全文

摘要： 大体来说，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 阅读全文