共 2 篇相关文章
这篇文章聚焦于分布式缓存主从架构中一个典型的“踩坑”场景：当master节点突发故障时，原本设计用于保障数据一致性的CAS（Compare-and-Swap）流程却会导致slave副本数据静默过期。作者从实际业务故障出发，剖析了问题根源——master cas失败后并未对slave执行set操作，导致新变更无法写入缓存。 文章进一步探讨了自动切换master角色为何不可行，以及手工切换或采用“delete slave”或“设置短过期”等补救方案时，仍需面对命中率下降、接口职责模糊等棘手权衡。最终，作者将问题抛回给读者：在这种对可用性与一致性都有要求的场景下，一个更完美的解决方案应该如何设计？
这篇讲的是MySQL中`ALTER TABLE`操作背后的运行原理。当执行这条命令时，数据库并非直接修改原表，而是先创建一份原表的临时副本，在副本上进行所有修改操作，完成后再删除旧表并将新表重命名。这种“复制-修改-替换”的策略保证了操作的原子性。 作者进一步解释了这个机制对业务的影响：在修改过程中，其他用户仍然可以读取原表的数据，但任何写入操作都会被暂时阻塞。直到新表完全准备好并接管后，这些被挂起的修改请求才会自动应用到新表上。这意味着`ALTER TABLE`操作可能会引发短暂的写延迟，尤其是在处理大表时。 理解这个实现原理，能帮助开发者更合理地规划表结构变更，比如在低峰期执行，或者考虑使用在线DDL工具来减少对线上服务的影响。
