基于 MySQL 的B2C电商系统前端数据层架构
15 likes2,111 views
该文档讨论了基于MySQL的B2C电商系统前端数据层架构，包括高可用和可扩展架构的方案，实时推荐系统的数据层构建及分析推荐系统的必要性和技术难点。它提出通过集中化写入和分散读取来优化产品库与交易库的架构，提高用户体验和产品销量。该文档还包括架构设计中的数据同步和数据分析策略，重点在于如何有效管理和分析用户行为数据。
基于 MySQL 的B2C电商系统前端数据层架构
- 1. B2C电商系统前端数据层架构 - 基于分布式 MySQL 数据库 简朝阳 @麦包包 2011.4.23 http://www.mbaobao.com 2011/4/23 1
- 2. 基于 MySQL 的 B2C电商系统前端数据层架构 简朝阳(sky000) Oracle ACE (Expertise MySQL) 技术保障部 @麦包包 http://isky000.com http://twitter.com/sky000 http://weibo.com/isky000 2011/4/23 2
- 3. 主题内容 1. 基于MySQL的常见高可用可扩展方案 业界常见高可用可扩展架构分析 2. 基于日志解析的准实时同步对架构进行扩展 结合 B2C 电商的特点，利用开放的复制协议对常规架构进行扩展 3. 基于用户访问行为的实时推荐分析系统数据层 作为电商，除了让用户方便的找到想要的产品的同时，还 希望让用户尽可能多的看到可能感兴趣的产品。该如何构 建一个分析推荐引擎的数据层？ 4. Q/A 2011/4/23 3
- 4. 常见架构-高可用 • 硬件高可用 • 冗余 主机/储存/电源/网络 … … • 数据高可用 • 共享 SAN/NAS/iScsi/SAS … … • 冗余 Replication/DadaSyncer … … 2011/4/23 4
- 5. 高可用架构 – 共享 2011/4/23 5
- 6. 高可用架构 – 冗余 2011/4/23 6
- 7. 高可用架构 – 冗余 2011/4/23 7
- 8. 高可用架构 – 冗余 2011/4/23 8
- 9. 高可用架构 – 冗余 2011/4/23 9
- 10. 常见架构-可扩展 • 向上扩展 • 升级/增加/更换硬件 CPU/内存/磁盘 … … • 向外扩展 • Sharding 垂直/水平/ … … • Replication • Cache/Search 2011/4/23 10
- 11. 可扩展架构 – Sharding 2011/4/23 11
- 12. 可扩展架构 – Sharding 2011/4/23 12
- 13. 可扩展架构 – Sharding 2011/4/23 13
- 15. 架构扩展- B2C网站特点 • 产品数量基数不大，变更频率较低 • SKU数量基数不会太大，一般不会过千万级别 • SKU信息变化频率较小，基本上都是公司内部运营人员操 作，并发量小 • 产品数据并发访问量大 • 在线平台并发访问量大，且高峰时段集中 • 系统整体读多写少 • 读远远大于写，甚至超过10:1 • 和后端仓储库存物流交互复杂 • 和后端系统的交互较多，逻辑比较复杂，系统间数据同步 实时性要求较高 • …… 2011/4/23 15
- 16. 架构扩展- B2C网站应对策略 • 写入集中化，读取离散化 • 写入操作集中到一个核心数据库，方便后台管理维护 • 利用 MySQL 开发的复制协议，实时获取 MySQL Binlog 信息按 模块/类别/… 将数据分发至各个提供读取服务 的数据库节点 • 交易库与产品库分离 • 产品库读多写少，交易库写多读少，优化模型不一样， 可用性要求也不一样。 • 利用Binlog进行数据同步/分发，提高复制灵活度和效率 • 减少和后端的交互节点 • 跨系统交互维护成本高，开发复杂，出现异常的概率也 高。减少交互节点可以充分极大减少系统异常概率和交 互系统开发和维护成本 2011/4/23 16
- 17. 架构扩展- 写入集中,读取离散 2011/4/23 17
- 18. 架构扩展- 交易库/产品库分离 2011/4/23 18
- 19. 架构扩展- 减少和后端的交互节点 2011/4/23 19
- 20. 分析推荐系统-必要性 • 提升用户体验 • 降低用户查找成本，节约用户搜索时间 • 提升用户友好度，提升品牌形象 • 提升销量 • 提高滞销品曝光率，提高因曝光率不够导致滞销的产品 销量。 • 根据用户购买行为提升相关配套产品曝光率和销量 • 根据用户兴趣推荐相关产品激发用户购买欲 • … … 2011/4/23 20
- 21. 分析推荐系统-技术难点 • 基础数据难以收集 • 该收集哪些数据？哪些有用哪些没用？ • 数据量大，如何有效过滤无用数据？ • 收集范围广，如何降低收集程序的影响？ • 收集结果难以分析 • 收集结果数据量大，通过传统的关系型数据库或者是常 规日志分析工具难以处理。 • 分析模型各家都不一，没有合适的商业软件满足需求。 • 分析结果难以实时呈现 • 数据分析运算复杂，分析需要消耗较大量资源 • 用户在线时间不会太长，分析结果难以从离线分析系统 及时反馈在前台应用 2011/4/23 21
- 22. 分析推荐系统-架构组成 • 以关系型结构化方式将用户行为记录在MySQL中 • 以 BlackHole 存储引擎作为行为记录的基础表引擎 • 以 MySQL Infobright 对行为数据进行存储/分析 • 实时解析Binlog将行为数据发送至分析引擎数据中心 • 应用以标准的 SQL 接口对行为数据进行分析 2011/4/23 22
- 23. 分析推荐系统-数据层架构 2011/4/23 23
- 24. 分析推荐系统-理由 • 为什么不直接以文件存储用户行为信息 • 统一存储，统一接口，统一维护 • 为什么不用Hadoop/Greenplum等分布式计算系统 • 离线运算能力强，并发能力弱 • 为什么选择 MySQL Infobright • 标准 SQL 接口 • 列式存储，压缩比大 • 并发能力较高，可提供在线运算 • 知识网格技术/先进的优化器 • … … 2011/4/23 24
- 25. 分析推荐系统-Infobright 2011/4/23 25
- 26. END Q/A http://isky000.com 2011/4/23 26