解密电商系统架构发展历程( 二 )

解密电商系统架构发展历程
文章插图
 
【解密电商系统架构发展历程】 

存在的问题:下单之后到主库,然后立马查询到从库 。这个时候主库信息还没同步到从库中,系统可能就报错了 。这种问题解决方案只有一个TDDL,sharding-jdbc 。
  • 6.java电商网站,读写分离,分库分表 。
 
解密电商系统架构发展历程

文章插图
 
 
proxy:应用程序在访问数据库的时候,中间拦了一层,通过拦截可以知道是select 还是insert,update判断是走主库还是从库 。proxy需要维护,维护高可用,协议要拦截性能要下降 。
应用层:shardingJDBC基于jdbc底层的请求原理,请求的时候改成sql的方式 。访问读库还是从库 。开发人员需要了解shardingJDBC的业务,增加了开发成本和学习的成本 。数据库管理需要 。
  • 7.java电商系统,增加搜索引擎和redis集群
 
解密电商系统架构发展历程

文章插图
 
 
search cluster 全量同步,和定时增量同步都是通过读mysql的binlog完成的 。解决数据库压力 。
redis cluster 通过缓存到redis中,直接从redis中获取,减少数据库的读写 。
CDN 通过将静态文件放到指定的服务器,通过CDN下载静态资源 。
(四)分布式时代
引文:商品模块和会员模块两个不同的人开发,他们是互相调用的关系,商品模块的人开发完毕了,但是会员模块的老铁说,今天不上了,这是不是很尴尬,商品模块的需要回滚到满足会员模块的,两个人就开始掐架了,我好心写了你让我回滚,会员模块的说其实我也不想,这个产品经理不让上 。随着系统越来越大,各个模块变成了系统,每个系统是由不同小组来完成的,为了满足互相之前不受影响,就开始服务化 。
  • 说说淘宝的HSF 和 dubbo
提供对Dubbo和HSF两个RPC框架的支持 。阿里巴巴第一代RPC框架Dubbo是国内第一款成熟的商用级RPC框架,已于2011年正式对外开源,目前已发展成为国内开源价值最高、用户使用规模最大的开源软件之一 。最新一代RPC框架HSF,全称High Speed Framework,也叫"好舒服","很舒服"框架,是阿里内部对这一款高性能服务框架的昵称,是一款面向企业级互联网架构量身定制的分布式服务框架 。HSF以高性能网络通信框架为基础,提供了诸如服务发布与注册,服务调用,服务路由,服务鉴权,服务限流,服务降级和服务调用链路跟踪等一系列久经考验的功能特性 。
 
解密电商系统架构发展历程

文章插图
 
 
他们之前的互相调用很复杂 。至少功能进行了解耦,会员和商品之前的依赖关系,会员上线失败只会局部的影响 。但是会产生一个问题互相的调用,占用更多的网络资源 。
  • 分库分表的方式继续优化
每个应用一个数据库不在整个使用一个数据库了,每个应用一个库,对于比较复杂的利于订单,产品通过sharding-jdbc来进行分表 。用的最多的hash取模的方式,hash比较均匀,避免数据热点的问题 。但是hash的方式不容易进行扩展,之后会说如何针对hash进行扩展 。
 
解密电商系统架构发展历程

文章插图
 
 
  • 消息中间件
异步和解耦,双11下单的量很大,从Notify>metaq>rocketMq都是一样的 。削峰填补 。下个单需要查库存,告诉统计系统,还有风控系统 。平常时候统计系统是不用的,而是双11的时候使用,总不能平常的时候把统计系统的代码注释吧?到双11在把代码放开,然后在上线 。利用rocketMq的来解决 。
  • 图片服务
  1. oss tfs的方式 。上传一次,公用的都可以拿到 。给每个图片识别一个号,第二次上传会读hash,如果这个hash已经存在就不在上传 。时间换空间的一个问题 。解决数据库的一个问题 。
  2. 数据库存储图片名称和路径,图片的物理地址存储到硬盘里面 。分布式肯定有问题!冗余AB服务器都存一份,或者搞个图片服务器 。不可取 。
  3. 流的方式储存到数据库里面 。占用硬盘资源,需要转码对数据库的IO 。


    推荐阅读