一、架构设计
1、首先最外层有一层网关层 mz-gatway ，在网关层 使用霸下等，将异常流量剥离出来
异常流量:1、爬虫，根据IP，如果是代理的话，根据协议头 request header 也可以判断出来
2、用户应用层，承接入口流量
包含了登录层设计
使用用户名和密码 登录然后服务端返回sessionId
这里有个问题，那我能否模拟sessionId，其实是可以的，这个没办法控制模拟sessionId，可以使用频次控制，比如某个人最多登录几次，ip，一天最多几次等；
3、业务逻辑层
处理用户的业务逻辑信息，核心层
4、数据持久层
处理与用户底层的交互设计
DB的交互
这里可以分为两个模块，分为两种情况：
1、访问自己的数据库，不存在超时的问题
2、访问远程的数据库，会存在超时的问题，需要统一处理；是否需要抛出异常，还是自己吃掉异常，不向上层用户透出
5、微服务向其他应用提供服务的client 接口层
因为是向其他应用提供，因此需要考虑尽量把引用的包做小，别人引用的时候更轻量，用户不关心他不需要的应用，
实现放在业务逻辑层；
6、预热层
富客户端的数据，专门处理富客户端的数据，放在缓存；
二、缓存设计
1、双缓存设计
在入口层：guava --redis 缓存（guava 如果key一致，则使用分布式事务锁，只允许一个key穿透到redis层）
redis 与数据库DB之前 使用sentinel限流；保护接口；
更新缓存 与数据库放在一个try事务里面；尽量把try做小；
guava的更新，可以考虑发送mq消息的形式；这样会全量更新；
2、常用的稳定数据，比如用户信息，场馆信息等，考虑富客户端设计；
三、日志设计
核心链路，异步日志打印，
日志统一，考虑只用手机号，或者用户ID 就可以查询日志；
考虑C端应用，只打印异常日志；
如果异常使用日志上报的形式；专门设计日志监控系统；
四、对于库存超售的设计
首先 不同的应用使用 mq同步消息，做幂等，比如扣减库存把订单号传过来，
然后发消息，这样如果异常的话，可以循环16次，如果再有问题，直接抛出异常，人工介入
然后在系统内部参考：库存回滚架构设计原则