如何设计一套API接口
考虑到API接口的分类可以将API接口分为开发API接口和内网API接口，内网API接口用于局域网，为内部服务器提供服务。开放API接口用于对外部合作单位提供接口调用，需要遵循Oauth2.0权限认证协议。同时还需要考虑安全性、幂等性等问题。
如何实现接口的幂等性：
唯—id：每次操作，都根据操作和内容生成唯一的id，在执行之前先判断id是否存在，如果不存在则执行后续操作，并且保存到数据库或者 redis等。
服务端提供发送 token的接口，业务调用接口前先获取token，然后调用业务接口请求时，把 token携带过去，务器判断token是否存在 redis中，存在表示第一次请求，可以继续执行业务，执行业务完成后，最后需要把redis中的 token删除。
建去重表：将业务中有唯一标识的字段保存到去重表，如果表中存在，则表示已经处理过了
版本控制：增加版本号，当版本号符合时，才能更新数据
状态控制：例如订单有状态已支付，未支付，支付中支付失败，当处于未支付的时候才分许修改为为支付中等
秒杀系统如何设计？
基于SpringCloud构建秒杀抢购活动，如何才能支持百万级级别以上访问 ？
设计原则：前台请求尽量少，后台数据尽量少，调用链路尽量短，尽量不要有单点
秒杀系统解决方案：
nginx：校验恶意请求，转发请求，负载均衡；
网关：安全过滤（拦截恶意请求）、幂等、高并发、限流、用户频率设计
业务层：分布式集群，多台机器处理，提高并发能力
Hystrix：对秒杀接口实现服务隔离防止雪崩效应
Ribbon：负载均衡，优化资源使用，防止资源的过载
前端：页面资源静态化，按钮控制，使用答题校验码可以防止秒杀器的干扰，让更多用户有机会抢到
redis：实现分布式锁对用户频率限制，集群搭建保证高可用，持久化数据；缓存热点数据（库存）；
MQ：异步形式，实现对商品的库存修改，削峰限流，MQ堆积订单，保护订单处理层的负载，
数据库：读写分离，拆分事务提高并发度，使用乐观锁机制(版本号)+库存>0判断防止库存超卖问题