Aaron的学习历程

目录; (一) 拆分实施策略和示例演示 (二) 全局主键生成策略 (三) 关于使用框架还是自主开发以及sharding实现层面的考量 (四) 多数据源的事务处理 (五) 一种支持自由规划无须数据迁移和修改路由代码的Sharding扩容方案 (一) 拆分实施策略和示例演示 第一部分：实施策略 图1.数据库分库分表(sharding)实施策略图解

两个并发事务同时访问数据库表相同的行时，可能存在以下三个问题： 1、幻想读：事务T1读取一条指定where条件的语句，返回结果集。此时事务T2插入一行新记录，恰好满足T1的where条件。然后T1使用相同的条件再次查询，结果集中可以看到T2插入的记录，这条新纪录就是幻想。 2、不可重复读取：事务T1读取一行记录，紧接着事务T2修改了T1刚刚读取的记录，然后T1再次查询，发现与第

背景 在很多互联网产品应用中，有些场景需要加锁处理，比如：秒杀，全局递增ID，楼层生成等等。大部分的解决方案是基于DB实现的，Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系。其次Redis提供一些命令SETNX，GETSET，可以方便实现分布式锁机制。 Redis命令介绍 使用Redis实现分布式锁，有两个重要函数需要介绍

Redis事务的分析及改进 Redis的事务特性 数据ACID特性满足了几条？  为了保持简单，redis事务保证了其中的一致性和隔离性；  不满足原子性和持久性； 原子性 redis事务在执行的中途遇到错误，不会回滚，而是继续执行后续命令；（违反原子性） 事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作；  中间某条指令的失败不会导致前面已做指令的

传统MySQL+ Memcached架构遇到的问题 　　实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题： 　　1.MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。 　　2.Mem