1. 保证session一致性的架构设计常见方法：
session同步法：多台web-server相互同步数据
客户端存储法：一个用户只存储自己的数据(容易占带宽)
反向代理hash一致性：四层hash和七层hash都可以做，保证一个用户的请求落在一台web-server上
后端统一存储：web-server重启和扩容，session也不会丢失
对于方案3和方案4，个人建议推荐后者：
web层、service层无状态是大规模分布式系统设计原则之一，session属于状态，不宜放在web层
让专业的软件做专业的事情，web-server存session？还是让cache去做这样的事情吧
2. 能否保证两个主库生成的主键一定不冲突呢？
1).设置不同的初始值，设置相同的增长步长 就能够做到。 数据双向同步后，两个主库会包含全部数据
2).由业务上游，使用统一的ID生成器，来保证ID的生成不冲突
3. 主库高可用，主库一致性，一些小技巧：
双主同步是一种常见的保证写库高可用的方式
设置相同步长，不同初始值，可以避免auto increment生成冲突主键
不依赖数据库，业务调用方自己生成全局唯一ID是一个好方法
shadow master保证写库高可用，只有一个写库提供服务，并不能完全保证一致性
内网DNS探测，可以实现在主库1出现问题后，延时一个时间(等待数据同步完成)，再进行主库切换，以保证数据一致性
4. 分布式ID生成器：
1).使用数据库的 auto_increment 来生成全局唯一递增ID
优点：简单，使用数据库已有的功能;能够保证唯一性;能够保证递增性;步长固定
缺点：可用性难以保证：数据库常见架构是一主多从+读写分离，生成自增ID是写请求，主库挂了就玩不转了
扩展性差，性能有上限：因为写入是单点，数据库主库的写性能决定ID的生成性能上限，并且难以扩展
改进：
冗余主库，避免写入单点;数据水平切分，保证各主库生成的ID不重复
每个写库设置不同的auto_increment初始值，以及相同的增长步长，以保证每个数据库生成的ID是不同的
优点：改进后的架构保证了可用性
缺点：a.丧失了ID生成的“绝对递增性”：先访问库0生成0,3，再访问库1生成1，可能导致在非常短的时间内，ID生成不是绝对递增的（这个问题不大，目标是趋势递增，不是绝对递增）
b.数据库的写压力依然很大，每次生成ID都要访问数据库
2).单点批量ID生成服务(有一个单独的id数据库生成器服务)
数据库写压力大，是因为每次生成ID都访问了数据库，可以使用批量的方式降低数据库写压力。
ID生成服务假设每次批量拉取6个ID，服务访问数据库，将当前ID的最大值修改为5，这样应用访问ID生成服务索要ID，ID生成服务不需要每次访问数据库，就能依次派发0,1,2,3,4,5这些ID了。
当ID发完后，再将ID的最大值修改为11，就能再次派发6,7,8,9,10,11这些ID了，于是数据库的压力就降低到原来的1/6。
优点：保证了ID生成的绝对递增有序;大大的降低了数据库的压力，ID生成可以做到每秒生成几万几十万个
缺点：服务仍然是单点;如果服务挂了，服务重启起来之后，继续生成ID可能会不连续，中间出现空洞（服务内存是保存着0,1,2,3,4,5，数据库中max-id是5，分配到3时，服务重启了，
下次会从6开始分配，4和5就成了空洞，不过这个问题也不大）;虽然每秒可以生成万几十万个ID，但毕竟还是有性能上限，无法进行水平扩展
改进：单点服务的常用高可用优化方案是“备用服务”，也叫“影子服务”，所以我们能用以下方法优化：
外提供的服务是主服务，有一个影子服务时刻处于备用状态，当主服务挂了的时候影子服务顶上。这个切换的过程对调用方是透明的，可以自动完成，常用的技术是vip+keepalived，具体就不在这里展开。
另外，ID-gen-service也可以实施水平扩展，以解决上述缺点（3），但会引发一致性问题
3). uuid/guid：
不管是通过数据库，还是通过服务来生成ID，业务方Application都需要进行一次远程调用，比较耗时。
有没有一种本地生成ID的方法，即高性能，又时延低呢？
uuid是一种常见的方案：
string ID =GenUUID();
优点：本地生成ID，不需要进行远程调用，时延低；扩展性好，基本可以认为没有性能上限
缺点：无法保证趋势递增；uuid过长，往往用字符串表示，作为主键建立索引查询效率低，常见优化方案为“转化为两个uint64整数存储”或者“折半存储”（折半后不能保证唯一性）
4).取当前毫秒数
uuid是一个本地算法，生成性能高，但无法保证趋势递增，且作为字符串ID检索效率低，有没有一种能保证递增的本地算法呢？
取当前毫秒数是一种常见方案：
uint64 ID = GenTimeMS();
优点：本地生成ID，不需要进行远程调用，时延低;生成的ID趋势递增;生成的ID是整数，建立索引后查询效率高
缺点：如果并发量超过1000，会生成重复的ID;这个缺点要了命了，不能保证ID的唯一性。当然，使用微秒可以降低冲突概率，但每秒最多只能生成1000000个ID，再多的话就一定会冲突了，所以使用微秒并不从根本上解决问题。
5).类snowflake算法:
snowflake是twitter开源的分布式ID生成算法，其核心思想为，一个long型的ID：
41bit作为毫秒数
10bit作为机器编号
12bit作为毫秒内序列号
算法单机每秒内理论上最多可以生成1000*(2^12)，也就是400W的ID，完全能满足业务的需求。
借鉴snowflake的思想，结合各公司的业务逻辑和并发量，可以实现自己的分布式ID生成算法。
缺点：由于“没有一个全局时钟”，每台服务器分配的ID是绝对递增的，但从全局看，生成的ID只是趋势递增的（有些服务器的时间早，有些服务器的时间晚）
5. 库存扣多了怎么办
1).用“设置库存”替代“扣减库存”，以保证幂等性。(同一个用户库存扣减时，可以引发重试机制，导致库存重复被扣)
2).使用CAS乐观锁，在“设置库存”时加上原始库存的比对，避免数据不一致
留言一
是否能使用：update stock set num=num-$count where sid=$sid and stock>=$count; 的方式扣减库存？
回答：这个方案无法保证幂等性，有可能出现重复扣减。
留言二
把库存放到reids里，利用redis的事务性来扣减库存。
分析：redis是如何实现事务操作的？本质也是乐观锁。
redis的性能之所以高，还是redis内存访问与mysql数据落盘的差异导致的。内存访问的不足是，数据具备“易失性”，如果重启，可能导致数据的丢失。当然redis也可以固化数据，难道每次都刷盘？redis真心没法当作mysql用。
最后，redis用单线程来避免物理锁，但mysql多线程也有多线程并发的优势。
回答：可以使用redis的事务性扣减库存，但在CAS机制上比mysql没有优势，高性能是因为其内存存储的原因，带来的副作用是数据有丢失风险，具体怎么用，还得结合业务折衷（任何脱离业务的架构设计都是耍流氓）。
留言三
支持幂等能否使用客户端token，业务流水？能否使用时间戳，版本号来保证一致性？ 回答：可以。
留言四
能否使用队列，在数据库侧串行执行，降低锁冲突？回答：可以。
留言五
能否使用事务？回答：容易死锁，吞吐量很低，不建议。
留言六
能否使用分布式锁解决，例如setnx, mc, zookeeper？
回答：可以，但吞吐量真的高么。
留言七
文章重点讲了幂等性和一致性，没有深入展开讲高吞吐，利用缓存抗读请求，利用水平扩展增加性能是提升吞吐量的根本方案。
回复：很中肯。
6. “Compare And Set”（CAS），是一种常见的降低读写锁冲突，保证数据一致性的乐观锁机制。(可以使用CAS简洁的保证不会生成重复的ID)
针对上述库存扣减的例子，CAS升级很容易，将库存设置接口执行的SQL：
update stock set num=$num_new where sid=$sid
升级为：
update stock set num=$num_new where sid=$sid and num=$num_old 即可。
什么是ABA问题
CAS乐观锁机制确实能够提升吞吐，并保证一致性，但在极端情况下可能会出现ABA问题。
什么是ABA问题？
考虑如下操作：
并发1（上）：获取出数据的初始值是A，后续计划实施CAS乐观锁，期望数据仍是A的时候，修改才能成功
并发2：将数据修改成B
并发3：将数据修改回A
并发1（下）：CAS乐观锁，检测发现初始值还是A，进行数据修改
上述并发环境下，并发1在修改数据时，虽然还是A，但已经不是初始条件的A了，中间发生了A变B，B又变A的变化，此A已经非彼A，数据却成功修改，可能导致错误，这就是CAS引发的所谓的ABA问题。
库存操作，出现ABA问题并不会对业务产生影响。
ABA问题的优化
ABA问题导致的原因，是CAS过程中只简单进行了“值”的校验，再有些情况下，“值”相同不会引入错误的业务逻辑（例如库存），有些情况下，“值”虽然相同，却已经不是原来的数据了。
优化方向：CAS不能只比对“值”，还必须确保的是原来的数据，才能修改成功。
常见实践：“版本号”的比对，一个数据一个版本，版本变化，即使值相同，也不应该修改成功。
总结
select&set业务场景，在并发时会出现一致性问题
基于“值”的CAS乐观锁，可能导致ABA问题
CAS乐观锁，必须保证修改时的“此数据”就是“彼数据”，应该由“值”比对，优化为“版本号”比对
文章转自公众号：架构师之路