[阶段总结]对于商城模块设计的多阶段总结

[TemplarJQ]

分布式扩展的总结

所用技术

• nginx反向代理
• 数据库集中访问
• redis分布式会话存储

问题分析

• 水平扩展除了nginx反向代理还有哪些？

  • 宏观上，流量并发特别大的话可以四级负载均衡lvs+keepalived；为了高可用和离用户更近可以异地多活多机房部署； 微观上，可以使用spring cloude的zuul + eruake + ribbon实现应用水平扩展
  • 对于无状态的服务器水平扩展依靠负载均衡点或者客户端缓存负载均衡路由表及可实现 有状态的数据服务器则要考虑分片和应用改造

• 数据库如何水平扩展

  • 读写分离，一主多从，主从弱一致性保证性能。这样应用就会面临读过期数据的问题，需要在业务层上做折中，若业务需要读到强一致数据就读主库，主库可以采取keepalive方式同另一个不开放的主库做同步，但为了性能考虑一般不对两个主库做双写，发生问题切换的时候需要应用层做好failover机制。
  • 分库分表。对于join，orderby这种尽可能使得其可以路由在同一个分片区保证性能否则等于跨数据库查询，性能很差，若无法做到路由位控制的就存储冗余数据，分布式事务的话是另一个话题，有多种方式保证。
  • 无论以上哪种处理方案，都记住cap理论，也就是分布式的情况下可用性和强一致性只能选其一，架构师不要花心思在中间件怎么又能保证c又能保证a上，而应该考虑在出现问题的时候怎么恢复数据，或者索性就跟hbase一样作强一致性数据库。

• Nginx容器作为反向代理中间节点如何保证路由策略的性能高效？

  • 使用keepalive可以解决网络重建问题，同时nginx的进程模型可以保证非阻塞式的高性能运行

[TemplarJQ]

缓存技术的总结

现有架构设计图

所用技术

• 多级缓存技术
• Nginx缓存技术

问题分析

• 脏读和失效
  • 缓存脏读某种程度不可避免，避免脏读还要考虑业务容忍性（这个要根据业务区分）
• Redis与服务器之间网络瓶颈
  • nginx内存足可以使用lua shared dic降低依赖
  • 单台不足可以lvs+keeplived+n台nginx服务器内存扩展
  • redis cluster，把读业务引入到slave上，并且使得各集群不在同一网段，避免同一出口瓶颈
• Nginx感知过多业务，是否可以进行分层，如何设计？
  • 分层加负载均衡
  • nginx配置可以多层，然后统一写到主配置文件中，做到内容隔离
  • 为确保多层nginx性能可以使用keepalive连接到第二层nginx