这个是在公司分享的一个ppt，整理下发到博客里，记录下，也是避免忘记了
一．幂等性
二．数据库
三．代码默认写法
四．业务设计
一、幂等性
概念
不管调用多少次，都应该 产生一样的效果和 返回一样的结果
案例：
1. 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果。
2. 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱
3. 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的
4. 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题。
技术实现（一）
查询操作
查询一次和查询多次，在数据不变的情况下，查询结果是一样的。
select是天然的幂等操作。
技术实现（二）
删除操作
删除操作也是天生幂等的，删除一次和多次删除都是把数据删除。
(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个)
Select * from table_xxxwhere id=#id;
不抛出异常，删除操作都返回true, 注意Dao层代码写法
技术实现（三）
唯一索引，防止新增脏数据
案例：
支付宝的资金账户，支付宝也有用户账户，每个用户只能有一个资金账户，怎么防止给用户创建资金账户多个，那么给资金账户表中的用户ID加唯一索引，所以一个用户新增成功一个资金账户记录要点：唯一索引或唯一组合索引来防止新增数据存在脏数据（当表存在唯一索引，并发新增报错时，再次调用接口会返回成功结果）
注意点：
先查询，用唯一索引来查，后新增，新增控制幂等
技术实现（四）
token机制，防止页面重复提交
业务要求：页面的数据只能被点击提交一次
发生原因：由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交
解决办法：集群环境：采用token加redis（redis单线程的，处理需要排队）单JVM环境：采用token加redis或token加jvm内存
处理流程：1. 数据提交前要向服务的申请token，token放到redis或jvm内存，token有效时间2. 提交后后台校验token，同时删除token，生成新的token返回
token特点：要申请，一次有效性，可以限流注意：redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用
技术实现（五）
悲观锁
获取数据的时候加锁获取，进行业务操作在提select * from table_xxxwhere id = 'xxx' for update;
建议使用悲观锁：账户一个人拥有，铜宝账户，积分账户，会员等级账户
不建议使用：产品份额账户。。。几百个人抢一个份额
注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用，数据库引擎要用Innodb，支持行锁
技术实现（六）
乐观锁
乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。乐观锁的实现方式多种多样可以通过version或者其他状态条件：
1. 通过版本号实现update table_xxxset name=#name#,version=version+1 where version=#version#
2. 通过条件限制update table_xxxset avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# >= 0
增加额外表来保证单条记录的幂等，一个用户一个幂等。
要求：avai_amount-#subAmount# >= 0 ，这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高注意：乐观锁的更新操作，最好用主键或者唯一索引来更新,这样是行锁，否则更新时会锁表，上面两个sql改成下面的两个更好update table_xxxset name=#name#,version=version+1 where id=#id# and version=#version#update table_xxxset avai_amount=avai_amount-#subAmount# where id=#id# and avai_amount-#subAmount# >= 0
技术实现（七）
分布式锁，拿不到conn
还是拿插入数据的例子，如果是分布是系统，构建全局唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。要点：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁(分布式锁要第三方系统提供)
技术实现（八）
select + insert
并发不高的后台系统，或者一些任务JOB，为了支持幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了
注意：核心高并发流程不要用这种方法，每天只执行几次的任务，建议使用，性能好一点
技术实现（九）
状态机幂等
在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机(状态变更图)，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。
注意：订单等单据类业务，存在很长的状态流转，一定要深刻理解状态机，对业务系统设计能力提高有很大帮助
技术实现（十）
对外提供接口的api如何保证幂等
如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)
重点：对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。注意，为了幂等友好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际已经处理了。
二、数据库
数据库设计原则
字段的命名规范化，简洁易懂，cash—取现，不合理，withdraw合理些
字段名要有注释，方便后人(不是死了的)查找问题
主键是选择自增的方式，还是带业务含义的主键，还是一个自增方式主键+ 一个业务含义流水要考虑清楚
字段长度选择，字符串考虑未来扩展性问题，整形有很多种，int(11)和int(2)，在性能上并没有优化
数据库引擎选择innodb
是否有幂等性业务需求靠数据库唯一索引来完成，索引设置的合理性
Decimal的长度选择，保留小数点后6位
同一个系统中各个表中同样含义的字段，名词要一致hk_detail,,HkDetail
同一个系统前缀一致，tb_share,tb_income_expense, tbShareId, shareId其他表里面存储的（MBA智库百科，查询金融词汇）
主键的设计
每个表都应该设置一个ID主键，最好的是一个INT型，并且设置上自动增加的AUTO_INCREMENT标志，这点其实应该作为设计表结构的第一件必然要做的事！！
个人强烈建议：自增id主键+全局唯一序列号
100xxxxxx-广东省, 200xxxxxx-黑龙江
遍历需求的对于自增ID的表来说很容易实现
主键设计：
1.自增
2.15位时间戳+业务标志+rand 32
3.分布式全局唯一，UUID或额外系统主键生成系统支持
数据库字段长度的优化
类型
占用字节
范围
tinyint 1 -128~127
smallint 2 -32768~32767
mediumint 3 -8388608~8388607）
int 4 -2147483648~2147483647
bigint 8 +-9.22*10的18次方
原则：
不浪费空间, 能用小的数据类型干嘛占用那么多空间
方便以后扩容
能用int，不影响业务理解，不用char
Tinyint(30)------30个字节---10, 000000000000000000010,
例子
direction收支方向，就收和支两个值，一定用tinyint(1)
数据库表名的命名
原则：
同一个应用都相同前缀，如tbj_aaa,tbj_bbb
简洁，见名知意
数据库字段的命名
原则：
同一个含义的字段各个表中名称一致
尽量用专业词汇
简洁，见名知意
例子
持仓的专业词汇是position，份额是share，所以份额表示tb_share
用户份额id，没有用tb_share_id而是用share_id，简洁易懂
设计索引
原则：
根据业务需求设计索引
索引不要过多，影响插入更新性能
如果有幂等性需求，设置数据库唯一索引
例子
如铜板账户，userId设置为唯一索引，一个人只能有一个铜板账户
收支流水表的userID设置普通索，查询效率高
Create_time默认加索引。。。。
A,b,c组合索引，，A**，ABX XXB XXC, a+b+c, 按位加索引
字段类型的选择
原则：
整形效率高于字符串，高于datetime
时间long形式时间建议加
日期：int20121212，2100000 2010000
长度过程用text，remark，varchar1024，默认截取，前端，append，/n
如果表数据量很大，主键用bigint
例子
occur_date用整形不用datetime，20121212，查询频繁用整形效率高
因为每个表未来的数据量都会很大，用bigint
如何避免全表扫描，如何避免误删数据
原则：
全表扫描会造成数据库挂掉,OOM
索引值很少，走索引也会全表扫描
删数据时，加limit限制和where后必须有条件
例子
DAO层面限制不走索引的查询sql
DAO层面限制索引值少的查询sql
Delete from tb_positionwhere id=142343 limit 1;
怎么分表？
深入理解业务，根据业务特性来分表，根据查询需求来分表
案例：
1.代金券分表（季度分）
2.每日收益分表（userId取余）
3.对账分表（按月分）
4.微信红包分表（年度+用户分）
分表后怎么查询？
前端要配合改，尽量不支持后台聚合查询
案例：
I.微信红包查询收支明细, 只能按年查询
II.按月查询
III.查询历史等
缓存和DB数据一致
索引字段上进行运算会使索引失效
尽量避免在WHERE子句中对字段进行函数或表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
SELECT * FROM T1 WHERE F1/2=100 应改为: SELECT * FROM T1 WHERE F1=100*2
禁止如下sql：
Select * from table_xxxwhere nvl(filed_xx)=xxx;(红色字体不能加函数)
Sql的编写
一个xml里不要有两个表名，不做关联表查询，因为mysql接不了那么多客
下面的写法不对，不要给字段加函数
Sql通用查询的优化
Sql1：
select * from coupon where status=1 and use_time>’2016-03-14 00:00:00’ and use_time<’2016-03-15 00:00:00’;
Sql2：
select * from coupon where use_time>’2016-03-14 00:00:00’ and use_time<’2016-03-15 00:00:00’and status=1;
默认前提：
status，use_time都是索引字段
由于where后面索引一般生效顺序是从前到后，所以sql1是先走索引status再走use_time,sql2是先走索引use_time，后走status。
优化手段：先走的索引影响条数越少越好
三、代码默认写法
如何保证小数点后计算准确性
1.保留两位有效数字的值，要保留小数点后六位BigDecimal进行计算
案例：
非标产品收益
2. 保留六位有效数字的值，要保留小数点后20位BigDecimal进行计算
案例：
铜宝账户
SimpleDateFormat不是线程安全的
每次要new，不new，原因都查不到
如何避免全表扫描和误删数据—DAO层就禁止掉
日志是为了查问题，所以怎么记日志？
用户ID，异常原因这是必须要记录的，其他的业务关键信息也要记录下来
核心业务流程，请求参数，执行完业务影响数据要记录下来，info日志
核心业务流程，执行时间要记录下来，info日志
一个类中每条日志都要是唯一的，不然你怎么知道是那块代码出来的日志
日志要漂亮，要格式化，打印出来的才漂亮
案例：
出问题了可不可以立即关掉，开关？
核心业务系统要有开关，重大异常时可以随时关掉,，服务降级
案例：
交易系统全局开关，新手体验金开关
只用一次的系统，单独开发，独立部署
一些促销活动和营销活动临时开发，要临时部署，不要影响主业务系统
案例：
支付宝5福
15年春晚微信摇一摇
activity
经常扩展的常量类用java类不用枚举
枚举在增加变量，新老版本，序列化，反序列化中不太友好
JOB什么标准？
支持重复执行，幂等，这是基础
F(x)，F(Y) 是两个幂等操作：所以：f(x) +f(y)也是幂等的
JOB跑一半断电了，支持重跑修复
JOB返回结果要有，查询多少数据，处理了多少，失败了多少，成功了多少
JOB执行时间比较久的，继承AbstractJob来写，支持中断, sorce->trade>
几个JOB之间应该是互斥关系，可以独立跑，不要搞依赖
代码看着要美丽，漂亮
不要有黄点提示
不要用deprecate的方法和类，慢慢改掉
特别长的方法名，类名不漂亮
代码块是个方块，一行不要超一屏幕，横着拉代码太难看
竖着不要超过一屏幕，一个原理
嵌套不要超过三层，看不懂
一句话解决的，不要写一堆。啰嗦，多用apache工具类
代码看着要有结构感觉，不要不换行
注释要点睛
一个流程多次用到的数据，提前放内存
一些DB的配置数据，dubbo调用的获取的需要多次使用的数据等
查询一次，放到内存，多次使用，不用每次用到再去查询
敏感信息，加密
身份证，姓名，银行卡号，密码等核心数据，存储时要加密存储
看业务需求，哪些字段还需要加密
考虑加密算法的性能
RSA < DES < AES < MD5
MD5----》签名----》完整性，正确性
RSA----》加密----》安全性
加密算法的安全性
看复杂度选择,一般和性能成反比
去掉过多的if else
改成键值对配置形式，取配置便于维护，配置的选择看情况
数据库、应用、前端、含义的一致性
一个含义的字段，要用一个英文单词，别多个英文单词一个含义，搞死人的
怎么做遍历？
有自增主键的遍历
select * from table_xxxwhere status = #status and limit 1000; id > #lastQueryId
优点：性能高，不漏数据，遍历数据状态变更不会造成位移
缺点：暂时没发现
非自增主键遍历
select * from table_xxxwhere status = #status and id > #lastQueryIdlimit 1000;
每次取出最后一条ID，进行下一次查询，性能极高，强哥推荐，好片
是否是带状态更新的遍历：
会可能存在位移差，存在漏数据
解决办法：
1. id>#lastId, limit 100, order没有自增主键
2. Create_time索引，create_time>=#lastCreateTime, limit 100;支持幂等
3. 存在新增数据的遍历，做临时表，临时表做业务重复判断。
4. create_time半开查询create_time>= egtCreateTimeand create_time<ltCreateTime
容错
异步怎么做？
同步怎么做，超时时间？
对方接口的承受能力？
容错代码是正常代码的2倍以上？
doPay，，，，超时了，，，但是它成功了。。。。反查。。。。
一眼看的懂。一眼看不懂，一定有问题
一眼看不懂，怎么维护
一眼看不懂是流程设计问题还是命名问题，反正是有问题的
业务领域也是，很清晰，看得懂
四、业务设计
怎样做重构？
复杂简单化
简单标准化
标准流程化
流程自动化
做成一个标准的模式，大家都认为这么做合理，这事就成了
案例：交易流程，充值流程，做成品牌
根据状态机设计业务
业务核心点
业务边界点
业务对接点
核心业务状态机
服务升降级
服务自动升降级
案例：
铜板街交易核心汇总，铜宝系统，卡券，可以挂。挂掉不影响交易