交易系统设计原则

高并发原则

服务化

Nginx进行负载均衡，随着调用方越来越多，考虑使用服务自动注册和发现（Dubbo和Zookeeper），有些系统访问量太大，会打垮服务，因此需要考虑服务的分组/隔离。
流量持续增加需要考虑有限流、黑白名单等
细节考虑：超时时间、重试机制、服务路由（动态切换不同分组）、故障补偿机制，这些都会影响系统的服务质量
总结：进程内服务->单机远程服务->集群手动注册服务->自动注册和发现服务->服务的分组/隔离/路由->服务治理（限流/黑白名单）

缓存银弹

没有银弹：该论述中强调由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。

  1. 浏览器端缓存
    1. 实现机制：对响应头的Expires、Cache-control进行控制；该机制适用于对实时性不太敏感的数据，如商品详情页、商家评分、评价、广告词等；
    2. 不足：对于价格、库存等实时要求比较高的数据，就不能做浏览器端缓存；
  2. App客户端缓存
    1. 在大促销时为了防止瞬间流量冲击，一般会在大促之前吧APP需要访问的一些素材（如 js/css/image等）提前下发到客户端进行缓存，这样在大促时就不用去拉取这些素材了；
    2. 首屏数据也可以缓存起来，在网络异常情况下还是有拖地数据给用户显示
    3. APP地图一般也会做地图的离线缓存；

  3. CDN缓存

    1. 有些页面、活动页、图片等服务可以考虑将页面、活动页、图片推送到离用户最近的CDN节点，让用户能在离他最近的节点找到想要的数据。
    2. 一般有两种机制:推送机制（当内容变更后主动推送到CDN边缘节点）和拉取机制(先访问边缘节点，当没有内容时，回源到源服务器拿到内容并存储到节点上)
    3. 两种方式各有利弊。使用CDN时要考虑URL的设计，比如URL 中不能有随机数，否则每次都穿透CDN回源到源服务器，相当于CDN没有任何效果。对于爬虫，可以返回过期数据而选择不回源。

  4. 接入层缓存

对于没有CDN缓存的应用来说，可以考虑使用如Nginx搭建一层接入层，该接入层可以考虑使用如下机制实现。

  • URL重写:将URL按照指定的顺序或者格式重写，去除随机数。
  • 一致性哈希:按照指定的参数（如分类/商品编号）做一致性Hash，从而保证相同数据落到一台服务器上。
  • proxy_cache:使用内存级/SSD级代理缓存来缓存内容。
  • proxy_cache_lock:使用lock机制，将多个回源合并为一个，以减少回源量，并设置相应的lock超时时间。
  • shared_dict:如果架构使用了nginx+lua实现，则可以考虑使用lua shared_dict进行cache，最大的好处就是reload缓存不会丢失。

此处要注意，对于托底（或兜底，指降级后显示的）数据或异常数据，不应该让其缓存，否则用户会在很长一段时间里看到这些数据。

  1. 应用层缓存
    1. 我们使用Tomcat时，可以使用堆内缓存/堆外缓存，堆内缓存的最大问题就是重启时内存中的缓存会丢失,此时流量风暴来临,则有可能冲垮应用;
    2. 还可考虑使用local rediscache来代替堆外内存;或在接入层使用shared_dict来将缓存前置，以减少风暴。
    3. local redis cache，通过在应用所在服务器上部署一组 Redis，应用直接读本机Redis获取数据，多机之间使用主从机制同步数据。这种方式没有网络消耗，性能是最优。
  2. 分布式缓存

    总结

    系统高可用方案

    image.png