【一个电商网站萌发的优化思考(1)】数据库分库读写分离

1. 一个手里的小项目

最近接了一个B2C外包,据称初期用户量大概2000,并发量希望能支撑得起至少300次访问每秒。老实说,这个需求来说,用普通的架构一个好点的服务器加点优化都是卓卓有余的了。。但是在重温完《淘宝技术这十年》这本书以后,心中悸动不已,幻想都够架构出一个几万乃至上十万的并发系统,但是实习的时候是做游戏前端,平时接的项目都是小项目,基本没接触过高大上的大项目,所以想对手中这个小项目进行步步优化,看看能到什么程度(当然了,后面可能换别的项目)。

2. 项目简述

目前项目的基本业务功能都已经完成实现,环境是LAMP,用的是一个基于国产框架Thinkphp的系统二次开发,本来习惯做的一套优化都停住了先,先跟着《淘》进行优化。而目前的项目系统服务端经过压力测试在500用户连接、200并发操作的返回时间符合理想预期(暂时未加入日志系统)。为了让目标最大化,这里把客户要求的目标用户量和并发量都乘以十倍。

项目是一个B2C的电商系统,主要模块分为商品模块,着装搭配信息模块,用户模块,订单模块。

3. 数据库优化——主从库分离

当前的系统数据库访问就是最简单的一个库,读写都在上面,优点就是简单。。缺点也很明显,就是数据库访问的瓶颈。因此,第一步的优化就是考虑主从分库(如下图)。进行主从库分离后主要有以下优点:

1. 读写效率得到提升,因为写操作比读操作更加消耗资源,分开后互不干扰

2. 存储容量增加,可多个从库存储不同表数据,通过数据访问层决定在哪个库读取,这里也带出联合查询等等的问题,这是后话。

3. 数据安全性,有了从库的备份,也使得数据的安全性有一定的保证,当然了,定时备份还是必不可少的。

4. 实际分析

从项目上来看,抛开日志系统来说,频繁的写操作主要集中在用户的评论和购买时候生成的订单信息,而主要的读操作就集中在商品信息、评论信息、订单信息、搭配文章信息,用户信息在用户行为角度考虑的话在B2C系统上读取频率相对较少。因此这里的设计是,一个主数据库:存储所有的信息数据,负责各种的写操作;从数据库1:负责存储订单信息、评论信息和搭配文章信息;从数据库2:负责存储商品信息。

5. 实现过程

// 通过搜索资料,MySQL就自带了主从库分库的功能,因为硬件设备的缺乏,这里的实验就把两个从库放在一个服务器上,换个端口。

// 主要的实现明天实验过后再更新

时间: 2024-10-11 09:10:29

【一个电商网站萌发的优化思考(1)】数据库分库读写分离的相关文章

DDD设计一个电商网站

DDD设计一个电商网站(十一)-- 最后的准备  阅读目录 前言 准备 实现 结语 一.前言 最近实在太忙,上周停更了一周.按流程一步一步走到现在,到达了整个下单流程的最后一公里--结算页的处理.从整个流程来看,这里需要用户填写的信息是最多的,那么在后端的设计中如何考虑到业务边界的划分,和相互之间的交互复杂度,又是我们需要考虑的地方.总体来说本篇讲述的内容在前几篇都有涉及,所以这次一次性处理的业务比较多,已经比较熟练的看官可以跳过本篇. 二.准备 主流的电商设计中结算页包含以下5个概念:选择收货

如何一步一步用DDD设计一个电商网站(八)—— 会员价的集成

阅读目录 前言 建模 实现 结语 一.前言 前面几篇已经实现了一个基本的购买+售价计算的过程,这次再让售价丰满一些,增加一个会员价的概念.会员价在现在的主流电商中,是一个不大常见的模式,其带来的问题是: 1.加大了运营的复杂度,会员价如何与促销结合,比如应在折前运用还是折后运用等. 2.如果是折前那么需要考虑满减类型促销的金额满足点门槛反而相对来说是提高了. 3.如果是折后那么享受了多重优惠,成本控制的时候需要考虑进去. 在我们这个练手的Demo中暂时决定让会员价在折后运用,并且仅在不满足满减促

如何一步一步用DDD设计一个电商网站(六)—— 给购物车加点料,集成售价上下文

阅读目录 前言 如何在一个项目中实现多个上下文的业务 售价上下文与购买上下文的集成 结语 一.前言 前几篇已经实现了一个最简单的购买过程,这次开始往这个过程中增加一些东西.比如促销.会员价等,在我们的第一篇文章(如何一步一步用DDD设计一个电商网站(一)—— 先理解核心概念)中规划的上下文映射图可以看到,这些都属于一个独立的上下文(售价上下文). 二.如何在一个项目中实现多个上下文的业务 一般情况下,为了更好的分而治之,把不同的上下文作为单独的service,然后通过rpc框架(如WCF)来对其

如何一步一步用DDD设计一个电商网站(四)—— 把商品卖给用户

阅读目录 前言 怎么卖 领域服务的使用 回到现实 结语 一.前言 上篇中我们讲述了“把商品卖给用户”中的商品和用户的初步设计.现在把剩余的“卖”这个动作给做了.这里提醒一下,正常情况下,我们的每一步业务设计都需要和领域专家进行沟通,尽可能的符合通用语言的表述.这里的领域专家包括但不限于当前开发团队中对这块业务最了解的开发人员.系统实际的使用人等. 二.怎么卖 如果在没有结合当前上下文的情况下,用通用语言来表述,我们很容易把代码写成下面的这个样子(其中DomainRegistry只是一个简单的工厂

如何一步一步用DDD设计一个电商网站(十)—— 一个完整的购物车

 阅读目录 前言 回顾 梳理 实现 结语 一.前言 之前的文章中已经涉及到了购买商品加入购物车,购物车内购物项的金额计算等功能.本篇准备把剩下的购物车的基本概念一次处理完. 二.回顾 在动手之前我对之前的购买上下文内对象做了一次回顾.先梳理一下已经在上下文内出现的领域对象,如图1所示: [图1] 在梳理的过程中,我把原来Cart.AddCartItem(string productId, int quantity, decimal price)重构为了Cart.AddCartItem(Produ

如何一步一步用DDD设计一个电商网站(七)—— 实现售价上下文

阅读目录 前言 明确业务细节 建模 实现 结语 一.前言 上一篇我们已经确立的购买上下文和销售上下文的交互方式,传送门在此:http://www.cnblogs.com/Zachary-Fan/p/DDD_6.html,本篇我们来实现售价上下文的具体细节. 二.明确业务细节 电商市场越来越成熟,竞争也越来越激烈,影响客户流量的关键因素之一就是价格,运营的主要打法之一也是价格,所以是商品价格是一个在电商中很重要的一环.正因为如此也让促销演变的越来越复杂,那么如何在编码上花点心思来尽可能的降低业务的

如何一步一步用DDD设计一个电商网站(五)—— 停下脚步,重新出发

阅读目录 前言 单元测试 纠正错误,重新出发 结语 一.前言 实际编码已经写了2篇了,在这过程中非常感谢有听到观点不同的声音,借着这个契机,今天这篇就把大家提出的建议一个个的过一遍,重新整理,重新出发,为了让接下去的DDD之路走的更好. 二.单元测试 蟋蟀兄在我的第三篇文章下面指出: 这点其实是我偷懒了,单元测试其实不单单在DDD中是一个很重要的一环,在我们崇尚敏捷,快速迭代的大背景下,有良好的单元测试模块可以保证快速迭代下的项目质量.有甚至可以使用测试先行的TDD模式. 单元测试的好处我就不多

电商网站,性能优化

问题: 1)当大型网站系统>10万人 一个小时内,会跟数据库交互10万次(国内有京东,淘宝),这就会出现数据库瓶颈,每个数据库最大连接数(socket)2000 在某一段短暂时间内1万人,会跟数据库发生1万次交互,2000-8000[30秒] 5000 3000 2000个用户很快就可以到页面 5000个用户访问页面比较慢 还有3000个用户会提示超时/服务器出现例外 这是访问性能的问题,原因是数据库瓶颈. 解决方案: 1>页面静态化 解决方案:使用模板技术(Velocity[9-10年]/F

(转)625某电商网站数据库宕机故障解决实录(上)

625某电商网站数据库特大故障解决实录(上) 原文:http://oldboy.blog.51cto.com/2561410/1431161 这是一次,惊心动魄的企业级电商网站数据库在线故障解决实录,故障解决的过程遇到了很多问题,思想的碰撞,解决方案的决策,及实际操作的问题困扰,老男孩尽量原汁原味的描述恢复的全部过程及思想思维过程!老男孩教育版权所有,本内容禁止商业用途. 目录: 625某电商网站数据库特大故障解决实录... 1 1接到电商客户报警... 1 1.1与客户初步沟通... 1 1.