天猫网站内容架构分析(跨机器跨机房的数据访问设计原则及注意事项！)

　　天猫网站内容架构分析(跨机器跨机房的数据访问设计原则及注意事项！)

　　1 系统高可用

　　面向用户的系统都需要7*24小时提供服务，所以系统的任何一个环节都不能有单点。

　　服务层：服务层需要跨机房、跨机房部署，依赖的外部服务也需要跨机房、跨机房部署，以保证系统及其依赖的系统服务的高可用。

　　存储层：无论是营销系统、订单系统、价格系统等，由于产生的数据与用户或sku发送相关，每天都会产生大量的数据，存储层也会每天存储大量数据，为了保证高可用，数据存储缓存、mysql或easysearch需要跨机器跨机房分布，以实现高可用。

　　2.高并发低延迟

　　某大型电商网站，用户访问量大。为了保证用户的在线体验，需要保证所提供的服务满足高并发、低延迟。亚马逊做过测试，页面延迟每隔一定时间，就会造成不同数量的用户流失。

　　为了达到这个目标，数据访问的设计原则是尽可能贴近用户。如果用户通过app访问，app端可以缓存的数据尽量缓存。如果是通过网页，静态资源等也需要缓存在浏览器中。静态资源也会缓存到 CDN 中，尽可能靠近用户。如果app、浏览器、CDN服务无法缓存，可以通过JVM缓存数据。如果数据量过大，会通过redis和memcache进行缓存。并发访问不直接与mysql交互。

　　为了备份数据，或者方便操作者的查询，BI工程师分析数据，然后需要将数据存储在mysql中，写入mysql的过程尽量异步写入。

　　对于对数据准确性要求特别高的系统，比如支付系统，数据尽量同步写入mysql。如果每秒支付次数较大，mysql采用分表设计。

　　3.业务系统大数据量

　　对于电子商务系统、营销系统、订单系统、价格系统等，都会产生大量的数据，必须综合考虑数据访问速度。

　　易查询、高可用等特点，对系统数据存储方案会有较高的要求。这往往是每个系统的负责人头疼的问题。甚至许多系统通常都有 COE，并且经常升级存储解决方案。常见的集中式存储系统及其优缺点如下：

　　存储系统

　　优势

　　缺点

　　评论

　　mysql

　　很好地满足ACID特性；支持查询多维度数据；支持*敏*感*词*数据存储和分库、分表读写；通过主从支持高可用；支持读写分离

　　大数据分库分表，维护成本高；功能开发成本高；跨表查询数据成本高；存储升级成本高。

　　大数据系统经常使用子库和子表。为保证表数据永远不会太多，需要dump历史数据

　　Redis

　　高性能读写

　　存储空间昂贵，交易支持不好；难以支持过于负责的维度相关查询

　　数据库

　　高性能读写（tp99大于10ms），大存储空间（PB级）

　　难以支持太负责的维度关联查询，事务支持不好

　　查询条件往往比较简单，使用存储系统查询历史数据场景

　　易搜

　　高性能读写，超大存储空间；支持维度查询数据

　　索引耗时，可能影响正常访问

　　4.监控告警4.1方法性能监控4.2方法可用性监控4.3调用监控（包括不同时间维度的调用）4.4 JVM状态监控4.5网络监控4.6 CPU监控4.7磁盘监控4.8数据库监控5.系统设计原则5.1高内聚低耦合原则5. 2易扩展原则5.3单一职责原则5.4一个类只负责一个职责5.5一个方法只负责一个职责5.6单一接口原则5.7 组合/聚合复用原理5.8 易维护性原理6、BI系统常用方案6.1 业务数据同步6.2 业务数据在仓库的存储和管理6.3 市场上常用的工具及其解决问题