宝宝树的网站架构运维总监刘秋岐《大型网站的数据库架构演变和优化之道》
了解阿里巴巴国际网站、慧聪网、环球资源网的概况、构架、会员类型以及买家在网站的基本操作流程
一、实验目的通过本门课程的学习是电子商务专业的同学掌握利用第三方交易平台从事国际贸易的相关知识。
了解阿里巴巴国际网站以及其他相关网站的基本功能及各功能的操作技巧，达到能利用这些网站来完成国际贸易业务；了解中国电子商务现状和发展趋势，了解电子商务的特点及对传统企业产生的影响及意义，了解阿里巴巴国际网站、慧聪网、环球资源网的概况、构架、会员类型以及买家在网站的基本操作流程并完成注册。
了解这些站点上产品和发布信息流程,网页制作模块等的使用技巧。
掌握各个网站进行国际贸易的流程和特点。
二、实验地点管理学院电子实验室三、实验项目实验一：阿里巴巴国际站1、阿里巴巴国际站概述定位:主要是全球中小企业的网上贸易市场，是全球范围的E-makertplace,除中小型企业外，大型企业也可以在阿里巴巴上进行交易。
核心价值:卖家行为、买家行为、工具①买家可以寻找搜索卖家并发布采购信息②卖家可以寻找搜索买家并发布公司及产品信息③为买家卖家行为提供了沟通工具,帐号管理工具特点:①互动：社区Community频道，客户可以了解贸易相关的知识，互相分享贸易经验，讨论贸易相关话题等等。
②可信：阿里巴巴国际站的海外TrustPass会员和中国大陆的Gold Supplier经过第三方的认证，增加了公司信息的可信度，使买家买得更放心。
③专业：人性化的网站设计、丰富类目、出色的搜索和网页浏览，简便的沟通工具、帐号管理工具④全球化网上贸易市场：客户遍布全球，同时阿里巴巴国际站具有全球影响力。
流量:1500万 PV/day；17,000新注册会员/day；150万 UV/day；1,700新公司上线/day；180,000新产品发布/day覆盖范围：全球最大B2B贸易市场；790万注册企业会员；覆盖超过200个以上国家和地区；覆盖超过42个进出口行业国际网站构架:导航搜索(Search) 类目(Browsed by Category) 社区(Community)导航栏将买卖双方最常用的六个功能模块进行了集成，它位于阿里巴巴国际站首页的右上角，由六个部分组成：搜索栏位于首页正上方很醒目的位置，它可以按照以下三种不同的方式来进行查找：类目位于首页的左侧，在这一区域按照产品的类别建立了Agriculture 等42个一级类目，一级类目下又有若干二级子类目，二级子类目下又有若干三级子类目，通过类目的一级一级查找，最后也是可以查找到相关的信息。
母婴社区的闭环之路,用电商塑造一个10亿美金公司
母婴社区的闭环之路，用电商塑造一个10亿美金公司随着女性经期助手美柚完成3500万美金C轮融资、大姨妈完成3000万美金C轮融资，女性社区辣妈帮完成2000万美金的B轮融资。
新的消费意识以及育儿理念普及，让女性社区，尤其是连接女人和孩子的母婴社区成为万众瞩目的蓝海市场。
针对越来越多的年轻妈妈在网上寻求教育孩子的有关专业知识、经验分享、导购方面的刚性需求，以及资本市场在母婴领域的积极跟进，毫无疑问这将会是下一个10亿美金的巨大市场。
目前宝宝树年营收已经高达几个亿。
成立于2007年的宝宝树，如今已从一个图片分享的网站，变成集合了社区、知识、记录、硬件、导购等诸多功能为一体的母婴产品。
宝宝树是如何打造它的商业闭环?如何迅速抢占移动端用户?以何种形式掘金10亿美金的母婴市场?以下是宝宝树创始人王怀南口述：卖场式的垂直电商没有未来在7年前，我们几个创始人有很浓厚的电商基因，但是没有选择电商，是因为我们觉得卖场式的垂直电商没有未来。
2007年的时候，我，邵亦波和孙志俊决定做宝宝树。
虽然邵亦波有ebay 易趣的经历，但是从一开始我们就确定了不做垂直电商。
那时候的红孩子气焰很猛，很多人都认为了它即将要上市了。
但是在价格上没有优势的红孩子，我们觉得它的未来是有缺陷的，它很容易被通用电商吞并掉。
即使是今天，电商在很大程度上还在打价格战，所以那是虎我们就想把这方面规避掉。
选择社区是因为我们觉得现在的妈妈是孤独无助的。
她们从孕期、迎接新生命、养孩子很多都是孤独无援的。
她们迫切需要解决的不是马上买到什么东西，而是如何抚养一个新生命。
尤其是现在，在我国，61%的90后妈妈怀孕是一个意外，在没有准备的情况下，她们更是孤独彷徨的。
新生儿生病了就跑到医院打点滴，她们不需要每天看见孩子，因为她们还无法完成角色转换。
一开始宝宝树还不知道怎么样给用户提供知识，也不知道怎样陪着80后的妈妈聊天。
但是当时数字化照片非常火，各种数码相机都很流行，当时所以干脆决定做一个相片分享社区，让妈妈们在宝宝树上分享照片。
固安捷案例
固安捷案例分享
营销背景
固安捷中国网站（）是全球领先的设备维护、修理和运作(MRO)工业分销商固安捷（Grainger）在中国建立的工业产品采购B2B电子商务平台，致力于成为中国企业工业产品采购的贴心顾问。
营销过程
电商站点在SEM上投入的必然性是众所周知的，身为全球工业品分销行业的风向标，如何利用搜索引擎快速在国内打开市场同样是固安捷中国需要关注的命题。
在SEO方面，这一命题的解决是与文军信息的合作开始的。
接手网站之初，双方就确认了一条基本优化思路（如图）：
自然，解决现有页面的收录问题就成为了优化的第一阶段。
从日志文件分析到蜘蛛爬行的引导，从网站架构分析到网站内链建议，从页面相似度监测到重复页面处理，从死链的删除到404页面的设置，从网站地图的上线到百度站长平台数据的提交，一步步走来，收录也在一步步的增长。
四个月时间，站点页面的百度收录率已经从开始时的3%达到了85%之多。
收录提升之余，通过有效的站内内容布置以及外链操作，排名及流量的提升自然是不在话下。
来自搜索引擎的自然流量在四个月内也
有了翻倍的提升。
当然，仅仅满足于现阶段的流量是远远不够的，新增页面成为了第二阶段的优化命题。
根据用户搜索意图构建关键词库，撰写页面内容，打造新增页面的差异，充分考虑用户体验便成为了日常性的工作。
营销效果
虽然过程是艰辛的，不过付出收到了回报。
6、7、8、9、10五个月的流量及订单数据（如下图）还是不错的。
坚持迎合百度，百度会抛弃你，坚持做对用户有益的事情，百度会迎合你！。
宝宝树经营中存在的问题及改进对策分析
宝宝树经营中存在的问题及改进对策分析问题一：用户体验不佳：宝宝树的用户界面设计过于繁杂，导致用户在使用过程中操作不方便，难以找到所需的功能。
宝宝树的服务器响应速度较慢，视频播放卡顿现象较为明显。
这些都给用户带来了不好的体验。
改进对策：1. 用户界面优化：对界面进行简化，按照用户习惯重新设计，提高用户的使用便利性；2. 技术升级：增加服务器的带宽和存储容量，提高服务器的响应速度，解决视频播放卡顿问题；3. 用户反馈机制：建立用户反馈渠道，及时了解用户的问题和需求，针对性地改进产品和服务。
问题二：内容质量参差不齐：宝宝树的内容来源比较混乱，质量良莠不齐。
有些内容缺乏专业性，无法满足用户的需求。
改进对策：1. 筛选内容提供商：选择合作伙伴时，要注重其专业性和内容质量，建立长期稳定的合作关系；2. 内容审核机制：建立严格的内容审核机制，确保内容的专业性和准确性；3. 优化内容分类和搜索功能：通过增加标签和关键词的方式，提高用户对内容的检索效率，让用户更轻松地找到所需内容。
问题三：用户粘性不高：宝宝树的用户粘性不高，用户流失率较高，很多用户只是在初始阶段试用了一段时间就不再使用。
改进对策：1. 用户个性化推送：通过分析用户的行为和偏好，为用户推送个性化的内容，提高用户的黏性；2. 社交化功能增加：增加用户之间的互动和社交功能，鼓励用户参与讨论和分享，增加用户的粘性；3. 提供长期复习计划：宝宝树可以提供长期的学习计划，帮助用户制定系统性的学习计划，提高用户的持续使用率。
问题四：市场竞争压力增大：宝宝树面临的市场竞争日益激烈，同类型的婴幼儿在线教育平台不断涌现，市场份额逐渐被分散。
改进对策：1. 提升产品差异化：宝宝树需要研发更多独特的产品功能，与竞争对手区分开来，增加用户的选择动力；2. 建立品牌认知度：通过加大营销力度和品牌推广，提高宝宝树的知名度，增加用户的选择信心；3. 与合作伙伴合作：与知名的教育机构、专家合作，提供更丰富的教育资源和服务，增加用户的黏性和信任感。
大型电商分布式架构设计与优化
大型电商分布式架构设计与优化本文主题为电商网站架构案例，将介绍如何从电商网站的需求，到单机架构，逐步演变为常用的、可供参考的分布式架构原型。
除具备功能需求外，还具备一定的高性能、高可用、可伸缩、可扩展等非功能质量需求（架构目标）。
本文大纲：1. 使用电商案例的原因2. 电商网站需求3. 网站初级架构4. 系统容量估算5. 网站架构分析6. 网站架构优化根据实际需要，进行改造、扩展、支持千万PV，是没问题的。
使用电商案例的原因分布式大型网站，目前看主要有几类：1.大型门户（比如网易、新浪等）；2.SNS网站（比如校内、开心网等）；3.电商网站（比如阿里巴巴、京东商城、国美在线、汽车之家等）。
大型门户一般是新闻类信息，可以使用CDN、静态化等方式优化。
而开心网等交互性比较多，可能会引入更多的NoSQL、分布式缓存、使用高性能的通信框架等。
电商网站具备以上两类的特点，比如产品详情可以采用CDN，静态化，交互性高的需要采用NoSQL等技术。
因此，我们采用电商网站作为案例，进行分析。
电商网站需求客户需求：•建立一个全品类的电子商务网站（B2C），用户可以在线购买商品，可以在线支付，也可以货到付款；•用户购买时可以在线与客服沟通；•用户收到商品后，可以给商品打分和评价；•目前有成熟的进销存系统，需要与网站对接；•希望能够支持3~5年，业务的发展；•预计3~5年用户数达到1000万；•定期举办双11、双12、三八男人节等活动；•其他的功能参考京东或国美在线等网站。
客户就是客户，不会告诉你具体要什么，只会告诉你他想要什么，我们很多时候要引导、挖掘客户的需求。
好在提供了明确的参考网站。
因此，下一步要进行大量的分析，结合行业以及参考网站，给客户提供方案。
其它的这里暂不展开。
需求功能矩阵需求管理传统的做法，会使用例图或模块图（需求列表）进行需求的描述。
这样做常常忽视掉一个很重要的需求（非功能需求），因此推荐大家使用需求功能矩阵，进行需求描述。
宝宝树组织架构
宝宝树（Babytree）是一家中国领先的母婴互联网公司，成立于2007年。
其组织架构主要包括以下几个部分：
1. 董事会：负责公司的整体战略规划、决策和监督。
2. 高级管理层：包括首席执行官（CEO）、首席运营官（COO）、首席财务官（CFO）等，负责公司的日常运营管理。
3. 业务部门：包括内容事业部、电商事业部、广告事业部、技术事业部等，负责公司各项业务的开展。
- 内容事业部：负责宝宝树网站和移动端的内容生产、编辑和运营，包括孕期、育儿、早教等各类母婴知识分享。
- 电商事业部：负责宝宝树旗下的电商平台“宝宝树商城”的运营，包括商品采购、销售、物流等。
- 广告事业部：负责宝宝树的广告业务，包括品牌广告、效果广告等。
- 技术事业部：负责宝宝树网站的技术开发、维护和优化，以及移动端APP的开发和维护。
4. 支持部门：包括人力资源部、财务部、行政部等，为公司提供后勤保障和内部管理支持。
5. 合作伙伴：与宝宝树合作的各类企业、机构和个人，共同推动母婴产业的发展。
Laudon-第15版-第9章-中文
9.2 供应链
针对如下环节的组织和流程的网络 物料采购, 把物料加工成产品, 并把产品分销出
去 上游供应链 公司的供应商、供应商的供应商, 以及管理这
些供应商关系的业务流程 下游供应链 负责配送产品到客户那里的组织和业务流程 内部供应链
耐克（Nike）的供应链
上游
签约 供应商
生产能力、库存水平、物流调度、支付条款
CRM软件功能
图9.8
• CRM软件产 品主要支持销 售、客户服务 和市场营销流 程, 集成多个 来源的客户信 息, 同时支持 运营与分析两 个层面
销售
账目管理 潜在客户管理
订单管理 销售计划 现场销售 销售分析
客户数据
市场营销
营销活动管理 促销渠道管理
事件管理 市场计划 市场运营 市场分析
客户服务
开篇案例: 斯酷凯蒂公司在云端运行ERP
问题
快速的全球增长 不完善的配送模型 落伍的人工流程
解决方案
调整业务流程 SAP Business ByDesign 云计算平台
斯酷凯蒂公司使用SAP Business ByDesign集成业务流程 与决策
本案例说明了为何公司需要企业应用 本案例表明了ERP系统可以显著提升运营效率和决策的能力
下一代企业应用（1/2）
企业解决方案/套装软件
应用系统更加柔性、基于Web应用、能与其他系统 集成
SOA标准 开源软件应用 随需应变的解决方案 具有基于云计算的版本 提供基于移动平台的更多功能
下一代企业应用（2/2）
社交型CRM 利用社交网络技术 公司社会化网络 通过脸谱网与客户互动 例如: Buzzient平台把企业应用和社会化媒体
图9.10
分析型CRM利用客户数据仓库与数据分析平台工具, 分析公司直接
社区网站修炼之道——phpwind产品架构全解析
，
可 以实现 大 型 社 区 网
。
产 品 形 态 上 支 撑 门户 论 坛 商城 和 个 人 空 间 ( 博 客 ) 等模 式
既 在产 品形 态 层 面 保 持 了 用 户 对 社 区 的统
一
站W e
、
搜 索服 务 器 和 数据 库 服 务 器 的 分 布 式 部 署
，
认知
，
又 在底 层
、
不 仅 大 大 提 高 大 型 社 区 站 内搜 索 的 效率
层面能帮助社 区网站更快速 、而且更健康的发展 。
社区基础元素是人、内容与关系。毫无疑 问人是社区最
核心的要素，无论单纯 的论坛 、门户抑或 Ｓ Ｎ Ｓ都无一例外。
ｐ ｈ ｐ ｗｉ ｎ ｄ ７ ． ５ 版本 ，以强化社 区 的内容展现 为基础，提 内容吸引了关注 内容的人群，独特 的内容和情趣相投的人群
就像 血 液
样 把 内容 和 关 系 真 正 连 接 到
，
、
起
．
。
当站点数 据量 过 大 时
采 用 普通 的 S Q L 查 询
，
，
查询速
针 对 传 统 论 坛 内容 有 余
创 造 了运 营环 境
为 了统
．
一
交 互 不 足 的情 况
，
，
p h p w in d 7 5 建
或 直 接 不 响应
．
甚 至 导 致 数据 库宕机
，
，
管理 会 员
一
内容
、
关 系和 应 用 等社 区 要 素
，
，
实 现 搜 索 与数 据 库 查 询 分 离
服 务器
解决大 数据量 时
：
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库优化——监
监——合理的监控报警和预警机制： 指标先行(制定指标，以此为基准进行优化比较） Mysql监控：
Mysql服务可用：监控test库的一张表可以写入之后立刻查询
Mysql 当前连接数、IOPS、CPU使用率、网络流量、QPS、TPS InnoDB缓存池：脏块的百分率、读命中率、缓存池利用率 InnoDB每秒读写量、InnoDB每秒从文件中读取/写入的次数 InnoDB日志：每秒日志物理写次数、每秒日志写请求数、每秒向日志文件完成的 fsync()写数量 临时表：创建到disk上的临时表的数量 (团购搜索项目)
监控工具：
Nagios (基本数值型监控，监控Mysql服务可用性、当前连接数等) Zabbix 可以根据监控数值绘图，可以保留历史数据，可以根据收集的数值做逻 辑运算，符合报警的条件即报警.
数据库优化——施
施——运维中的一些经验: 备份是最重要的，任何对表的操作都提前备份表 Sql审核，上线前对sql做审核，查看sql的执行计划，检查索引
Mysql server上线之前文件系统最好做好lvm，便于日后扩展空间，或者做
snapshot快速备份或者搭建从 定期做主从一致性校验，防止从库切换为主库发现问题 Slowlog 每日利用工具做reporting，工具： mysqlsla、 pt-query-digest 定时验证备份可用性
• innodb_adaptive_flushing_method 设置为 keep_average
• innodb_stats_on_metadata=0 关掉一些访问information_schema库下表而产生的 索引统计
• innodb_flush_neighbor_pages=0
• innodb_change_buffering=inserts • innodb_old_blocks_time=1000 (使Block在old sublist中停留时间长为1s，不会被 转移到new sublist中,避免了Buffer Pool被污染)
• 目前在宝宝树(母婴社区网站)负责网站的运维和架构 • 一枚热爱数据库技术的少年 • 邮箱：liuqiuqi@ • 个人微信号 acmore007 扫码见右边，欢迎技术交流，共同进步
先讲两个故事
某电商网站图书促销，我在购物车里 面塞了些书，点击“购买”按钮后， 浏览器迟迟没有响应… 当晚该电商公 司大老板发微博：“我已经紧急购买 采购了10台服务器，增强网站后台， 明天继续促销一天。” 第二天一上班，我再次点击“购买” 按钮后，悲剧的发现页面还是 “Service is too busy”.当晚贵司老 板发微博要请信息部同事喝茶(咖啡) 2012年年初， 上线之后，在春运期间因为大量 用户访问而崩溃，无法有效访 问，网站崩溃时间非常长。 该网站的技术引其业界各种讨论 的声音，不过后来该网站逐渐稳 定成熟起来。
MyISAM Key Buffer：平均每秒读/写命中率
MyISAM读写次数：每秒从缓冲池读/写次数、每秒从硬盘读/写次数 COMDML：每秒Delete、Insert、Replace、Select、Update语句执行次数
数据库优化——监
监——合理的监控报警和预警机制： 辅助监控：
Slowlog的每分钟/每5分钟的数目的统计曲线 对Binlog的一些定制化统计曲线(比如对订单表的更新次数曲线等)
数据库优化——软
软——操作系统层面：
文件系统推荐使用 XFS，挂载时候设置挂载属性noatime,nodiratime,nobarrier (nobarrier 是避免操作系统的cache) 关闭 numa=off 增加本地端口，以应对大量连接 echo ‘5120 65000’> /proc/sys/net/ipv4/ip_local_port_range 增加队列的连接数 echo ‘8192’> /proc/sys/net/ipv4/tcp_max_syn_backlog 设置连接超时时间 echo ’60’> /proc/sys/net/ipv4/tcp_fin_timeout
数据库优化——软
软——mysql优化调整层面：
• innodb_flush_log_at_trx_commit (根据安全性考虑可以设置为2日志先写到log_file 然后每隔1秒刷新到disk) • innodb_write_io_threads=16 (脏页写的线程数，加大该参数可以提升写入性能) • innodb_flush_method=O_DIRECT • innodb_adaptive_flushing 设置为 ON
数据库架构设计的重要性
电商网站——图书促销： • 能访问购物车，不能成功购买，问题出在订单系统 • 订单系统——数据库事务操作，缓存解决不了 • 事前的数据库伸缩性架构设计很重要 12306网站： • 高并发的数据库访问，全是数据库事务操作 • 逻辑运算的复杂性，例如有人购买了区间票 • 单台DB无法承载访问量的压力，根据压力横向扩展很重要
数据库优化——硬
硬——硬件使用层面：
数据库是三高系统(高CPU、高MEM、高IO) 选用大内存可以大大提升数据库，128/256G (国外有篇知名论文讲了数据库 性能提升选择大内存的方案是优于选择提升IO的方案的) SAS磁盘、SSD、PCIE-Flash 对比：
一般数据放在SSD盘上，日志放在普通磁盘上。
• 单个库表太多，查询的时候，打开表操作也消耗系统资源
• 单个表容量太大，查询的时候，扫描行数过多，磁盘IO大，查询缓慢 • 单个库能承载的访问量有限，再高的访问量只能通过分库分表实现
Mysql架构演进——分库分表
怎样合理分库分表：
• 一般按照业务来分库，避免跨库查询
• 分表有多种分法，大多按照主键id分表或者有区分度的主键字段分表 • 例如一些用户表的用户注册id是邮箱号(qweras345@)，这种可以 •按照id做MD5值，然后根据MD5串的第一位分16张表，按照第二位的话可以分 16*16=256张表等等
Mysql架构演进——一主多从,读写分离
一个主库，多个从库，主库写，从库负责查询，主库的ha通过keepalived实现， 从库读的高可用通过lvs或者haproxy实现 (haproxy修改权重生效慢)
Mysql架构演进——分库分表
为什么要分库分表？ • 单个库数据容量太大，单个DBServer存储空间不够
Mysql架构演进——主从
主从数据不一致：
主从机制是主将它的变更作为event发送给从，从将更改记录存成relay log放在本地，从 的sql_thread 执行relay log，这个过程中event发送和从执行relay_log中出现问题导致主 从数据不一致
解决办法：
使用percona-toolkit中pt-table-checksum和pt-table-sync做同步 重新从主库使用xtrabackup对innodb做在线热备然后做新的从库 使用了lvm的DBServer可以使用lvm的snapshot做数据快照进行数据拷贝而搭建新从 库(保证数据完全一致)
Mysql架构演进——主从
主从延时： 主库写多，从库单slave_sql_thread跟不上主库并发写，主从同步就会产生延时 解决办法： • 升级mysql至mysql-5.6.3，支持多线程的主从复制
• 使用MariaDB-10，可以实现并行复制
• 主库使用机械硬盘，从库可以使用SSD盘或者PCIe Flash，尽量使主从库一个机房 • sync_binlog=0 , innodb_flush_log_at_trx_commit = 0/2 • 拆主库，拆一个主库为两个主库
Mysql架构演进——分布式DB
分布式DB主要依靠Web前端到DBServer中间的DBProxy proxy功能： • mysql存活检测 • 主备库自动切换 • 读写分离，读请求负载均衡 • 分表读写 问题： MySQL协议解析、事务支持 产品： 官方：MysqlProxy 淘宝：Cobar 360 ：atlas
大型网站的数据库架构演变和优化之道
提纲
• 数据库架构设计的重要性 • 网站的数据库架构演进过程中遇到的问题
主从延迟、主从不一致 读写分离的高可用设计 分库分表 分布式Mysql DB集群
• 数据库集群的优化之道
软件层面的优化 硬件层面的优化 指标先行 软硬监“施”
刘秋岐
自我介绍
• 之前在搜狗和兰亭集势负责数据库的运维和架构设计
网站的数据库架构演进
随着网站壮大，Mysql数据库架构一般会经历如下演进：
主从(两台多 组) 一主多从(多台 读写分离)
分库分表
分库式DB
架构演进中会遇到的问题： 主从架构：主从延时、主从数据不一致了 一主多从：一主多从(读写分离)的高可用实现
分库分表：怎样合理分库分表
分布式DB：怎样设计分布式的Mysql DB集群，高性能高可用的实现DB路由