分布式架构系列:缓存

一、缓存概述

缓存是分布式系统中的重要组件,主要解决高并发,大数据场景下,热点数据访问的性能问题。提供高性能的数据快速访问。

1.1缓存的原理

(1) 将数据写入/读取速度更快的存储(设备);

(2) 将数据缓存到离应用最近的位置;

(3) 将数据缓存到离用户最近的位置。

1.2缓存分类

在分布式系统中,缓存的应用非常广泛,从部署角度有以下几个方面的缓存应用。

(1) CDN缓存;

(2) 反向代理缓存;

(3) 分布式Cache;

(4) 本地应用缓存;

1.3缓存媒介

常用中间件:Varnish,Ngnix,Squid,Memcache,Redis,Ehcache等;

缓存的内容:文件,数据,对象;

缓存的介质:CPU,内存(本地,分布式),磁盘(本地,分布式)

1.3缓存设计

缓存设计需要解决以下几个问题:

(1) 缓存什么?

哪些数据需要缓存:1.热点数据;2.静态资源;

(2) 缓存的位置?

CDN,反向代理,分布式缓存服务器,本机(内存,硬盘)

(3) 如何缓存的问题?

? 过期策略

1.固定时间:比如指定缓存的时间是30分钟;

2.相对时间:比如最近10分钟内没有访问的数据;

? 同步机制

1. 实时写入;(推)

2. 异步刷新;(推拉)

二、CDN缓存

CDN主要解决将数据缓存到离用户最近的位置,一般缓存静态资源文件(页面,脚本,图片,视频,文件等)。国内网络异常复杂,跨运营商的网络访问会很慢。为了解决跨运营商或各地用户访问问题,可以在重要的城市,部署CDN应用。使用户就近获取所需内容,降低网络拥塞,提高用户访问响应速度和命中率。

2.1CND原理

CDN的基本原理是广泛采用各种缓存服务器,将这些缓存服务器分布到用户访问相对集中的地区或网络中,在用户访问网站时,利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上,由缓存服务器直接响应用户请求。

(1) 未部署CDN应用前

网络请求路径:

请求:本机网络(局域网)——》运营商网络——》应用服务器机房

响应:应用服务器机房——》运营商网络——》本机网络(局域网)

在不考虑复杂网络的情况下,从请求到响应需要经过3个节点,6个步骤完成一次用户访问操作。

(2) 部署CDN应用后

网络路径:

请求:本机网络(局域网)——》运营商网络

响应:运营商网络——》本机网络(局域网)

在不考虑复杂网络的情况下,从请求到响应需要经过2个节点,2个步骤完成一次用户访问操作。

与不部署CDN服务相比,减少了1个节点,4个步骤的访问。极大的提高的系统的响应速度。

2.2 CDN优缺点

(1)优点(摘自百度百科)

1、本地Cache加速:提升访问速度,尤其含有大量图片和静态页面站点;

2、镜像服务:消除了不同运营商之间互联的瓶颈造成的影响,实现了跨运营商的网络加速,保证不同网络中的用户都能得到良好的访问质量;

3、远程加速:远程访问用户根据DNS负载均衡技术智能自动选择Cache服务器,选择最快的Cache服务器,加快远程访问的速度;

4、带宽优化:自动生成服务器的远程Mirror(镜像)cache服务器,远程用户访问时从cache服务器上读取数据,减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能。

5、集群抗攻击:广泛分布的CDN节点加上节点之间的智能冗余机制,可以有效地预防黑客入侵以及降低各种D.D.o.S攻击对网站的影响,同时保证较好的服务质量

(2)缺点

1.动态资源缓存,需要注意实时性;

解决:主要缓存静态资源,动态资源建立多级缓存或准实时同步;

2.如何保证数据的一致性和实时性需要权衡考虑;

解决:

a. 设置缓存失效时间(1个小时,最终一致性);

b. 数据版本号;

2.3CND架构参考

摘自《云宙视频CDN系统》

2.4 CND技术实践

目前,中小型互联网公司,综合成本考虑,一般租用第三方CDN服务,大型互联网公司,采用自建或第三方结合的方式。比如淘宝刚开始使用第三方的,当流量很大后,第三方公司无法支撑其CDN流量,淘宝最后采用自建CDN的方式实现。

淘宝CDN,如下图(来自网络):

三、反向代理缓存

反向代理是指在网站服务器机房部署代理服务器,实现负载均衡,数据缓存,安全控制等功能。

3.1缓存原理

反向代理位于应用服务器机房,处理所有对WEB服务器的请求。如果用户请求的页面在代理服务器上有缓冲的话,代理服务器直接将缓冲内容发送给用户。如果没有缓冲则先向WEB服务器发出请求,取回数据,本地缓存后再发送给用户。通过降低向WEB服务器的请求数,从而降低了WEB服务器的负载。

反向代理一般缓存静态资源,动态资源转发到应用服务器处理。常用的缓存应用服务器有Varnish,Ngnix,Squid。

3.2 Squid示例

Squid 反向代理一般只缓存静态资源,动态程序默认不缓存。根据从
WEB 服务器返回的
HTTP 头标记来缓冲静态页面。有四个最重要
HTTP 头标记:

Last-Modified: 告诉反向代理页面什么时间被修改

Expires: 告诉反向代理页面什么时间应该从缓冲区中删除

Cache-Control: 告诉反向代理页面是否应该被缓冲

Pragma: 用来包含实现特定的指令,最常用的是
Pragma:no-cache

Squid 反向代理加速网站实例

(1) 通过DNS的轮询技术,将客户端的请求分发给其中一台
Squid 反向代理服务器处理;

(2) 如果这台 Squid 缓存了用户的请求资源,则将请求的资源直接返回给用户;

(3) 否则这台 Squid 将没有缓存的请求根据配置的规则发送给邻居
Squid 和后台的
WEB 服务器处理;

(4) 这样既减轻后台 WEB 服务器的负载,又提高整个网站的性能和安全性。

3.2 代理缓存比较

常用的代理缓存有Varnish,Squid,Ngnix,简单比较如下:

(1) varnish和squid是专业的cache服务,nginx需要第三方模块支持;

(2) Varnish采用内存型缓存,避免了频繁在内存、磁盘中交换文件,性能比Squid高;

(3) Varnish由于是内存cache,所以对小文件如css,js,小图片啥的支持很棒,后端的持久化缓存可以采用的是Squid或ATS;

(4) Squid功能全而大,适合于各种静态的文件缓存,一般会在前端挂一个HAProxy或nginx做负载均衡跑多个实例;

(5) Nginx采用第三方模块ncache做的缓冲,性能基本达到varnish,一般作为反向代理使用,可以实现简单的缓存。

四、分布式缓存

CDN,反向代理缓存,主要解决静态文件,或用户请求资源的缓存,数据源一般为静态文件或动态生成的文件(有缓存头标识)。

分布式缓存,主要指缓存用户经常访问数据的缓存,数据源为数据库。一般起到热点数据访问和减轻数据库压力的作用。

目前分布式缓存设计,在大型网站架构中是必备的架构要素。常用的中间件有Memcache,Redis。

4.1Memcache

Memcache是一个高性能,分布式内存对象缓存系统,通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。简单的说就是将数据调用到内存中,然后从内存中读取,从而大大提高读取速度。

Memcache特性:

(1)使用物理内存作为缓存区,可独立运行在服务器上。每个进程最大2G,如果想缓存更多的数据,可以开辟更多的memcache进程(不同端口)或者使用分布式memcache进行缓存,将数据缓存到不同的物理机或者虚拟机上。

(2)使用key-value的方式来存储数据,这是一种单索引的结构化数据组织形式,可使数据项查询时间复杂度为O(1)。

(3)协议简单:基于文本行的协议,直接通过telnet在memcached服务器上可进行存取数据操作,简单,方便多种缓存参考此协议;

(4)基于libevent高性能通信:Libevent是一套利用C开发的程序库,它将BSD系统的kqueue,Linux系统的epoll等事件处理功能封装成一个接口,与传统的select相比,提高了性能。

(5)内置的内存管理方式:所有数据都保存在内存中,存取数据比硬盘快,当内存满后,通过LRU算法自动删除不使用的缓存,但没有考虑数据的容灾问题,重启服务,所有数据会丢失。

(6)分布式:各个memcached服务器之间互不通信,各自独立存取数据,不共享任何信息。服务器并不具有分布式功能,分布式部署取决于memcache客户端。

(7)缓存策略:Memcached的缓存策略是LRU(最近最少使用)到期失效策略。在memcached内存储数据项时,可以指定它在缓存的失效时间,默认为永久。当memcached服务器用完分配的内时,失效的数据被首先替换,然后也是最近未使用的数据。在LRU中,memcached使用的是一种Lazy
Expiration策略,自己不会监控存入的key/vlue对是否过期,而是在获取key值时查看记录的时间戳,检查key/value对空间是否过期,这样可减轻服务器的负载。

4.1.1Memcache工作原理

MemCache的工作流程如下:

(1) 先检查客户端的请求数据是否在memcached中,如有,直接把请求数据返回,不再对数据库进行任何操作;

(2) 如果请求的数据不在memcached中,就去查数据库,把从数据库中获取的数据返回给客户端,同时把数据缓存一份到memcached中(memcached客户端不负责,需要程序实现);

(3) 每次更新数据库的同时更新memcached中的数据,保证一致性;

(4) 当分配给memcached内存空间用完之后,会使用LRU(Least
Recently Used,最近最少使用)策略加上到期失效策略,失效数据首先被替换,然后再替换掉最近未使用的数据。

4.1.2Memcache集群

memcached 虽然称为 “ 分布式 ” 缓存服务器,但服务器端并没有 “ 分布式 ” 功能。每个服务器都是完全独立和隔离的服务。
memcached 的分布式,是由客户端程序实现的。

当向memcached集群存入/取出key value时,memcached客户端程序根据一定的算法计算存入哪台服务器,然后再把key value值存到此服务器中。

存取数据分二步走,第一步,选择服务器,第二步存取数据。

分布式算法(Consistent Hashing):

选择服务器算法有两种,一种是根据余数来计算分布,另一种是根据散列算法来计算分布。

余数算法:

先求得键的整数散列值,再除以服务器台数,根据余数确定存取服务器。

优点:计算简单,高效;

缺点:在memcached服务器增加或减少时,几乎所有的缓存都会失效。

散列算法:(一致性Hash)

先算出memcached服务器的散列值,并将其分布到0到2的32次方的圆上,然后用同样的方法算出存储数据的键的散列值并映射至圆上,最后从数据映射到的位置开始顺时针查找,将数据保存到查找到的第一个服务器上,如果超过2的32次方,依然找不到服务器,就将数据保存到第一台memcached服务器上。

如果添加了一台memcached服务器,只在圆上增加服务器的逆时针方向的第一台服务器上的键会受到影响。

一致性Hash算法:解决了余数算法增加节点命中大幅额度降低的问题,理论上,插入一个实体节点,平均会影响到:虚拟节点数 /2 的节点数据的命中。

4.2Redis

Redis 是一个开源(BSD许可)的,基于内存的,多数据结构存储系统。可以用作数据库、缓存和消息中间件。 支持多种类型的数据结构,如 字符串(strings),
散列(hashes), 列表(lists), 集合(sets),
有序集合(sorted sets) 与范围查询,
bitmaps,
hyperloglogs 和 地理空间(geospatial) 索引半径查询。

内置了 复制(replication),LUA脚本(Lua scripting),
LRU驱动事件(LRU eviction),事务(transactions)
和不同级别的 磁盘持久化(persistence), 并通过
Redis哨兵(Sentinel)和自动分区(Cluster)提供高可用性(high
availability)。

4.2.1Redis常用数据类型

1、String

  常用命令:set,get,decr,incr,mget 。

  应用场景:String是最常用的一种数据类型,与Memcache的key
value存储方式类似。

  实现方式:String在redis内部存储默认就是一个字符串,被redisObject所引用,当遇到incr,decr等操作时会转成数值型进行计算,此时redisObject的encoding字段为int。

2、Hash

  常用命令:hget,hset,hgetall 。

  应用场景:以存储一个用户信息对象数据,为例:

  实现方式:

  Redis Hash对应的Value,内部实际就是一个HashMap,实际这里会有2种不同实现。

(1) Hash的成员比较少时Redis为了节省内存会采用类似一维数
组的方式来紧凑存储,而不会采用真正的HashMap结构,对应的value redisObject的encoding为zipmap;

(2) 当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。

  3、List

  常用命令:lpush,rpush,lpop,rpop,lrange。

  应用场景:

  Redis list的应用场景非常多,也是Redis最重要的数据结构之一,比如twitter的关注列表,粉丝列表等都可以用Redis的list结构来实现。

  实现方式:

  Redis list的实现为一个双向链表,可以支持反向查找和遍历,方便操作。不过带来了部分额外的内存开销,Redis内部的很多实现,包括发送缓冲队列等也都是用的这个数据结构。

  4、Set

  常用命令:sadd,spop,smembers,sunion。

  应用场景:

   Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set
是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。

  实现方式:

  set 的内部实现是一个
value永远为null的HashMap,实际就是通过计算hash的方式来快速排重的,这也是set能提供判断一个成员是否在集合内的原因。

  5、Sorted set

  常用命令:zadd,zrange,zrem,zcard;

  使用场景:

   Redis sorted set的使用场景与set类似,区别是set不是自动有序的,而sorted
set可以通过用户额外提供一个优先级(score)的参数来为成员排序,并且是插入有序的,即自动排序。当你需要一个有序的并且不重复的集合列表,可以选择sorted
set数据结构,比如twitter
的public timeline可以以发表时间作为score来存储,这样获取时就是自动按时间排好序的。

  实现方式:

  Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里放的是成员到score的映射,而跳跃表里存放的
是所有的成员,排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。

4.2.2Redis集群

(1)通过keepalived实现的高可用方案

切换流程:

1. 当Master挂了后,VIP漂移到Slave;Slave
上keepalived
通知redis
执行:slaveof no one ,开始提供业务

2. 当Master起来后,VIP
地址不变,Master的keepalived
通知redis
执行slaveof slave IP host
,开始作为从同步数据

3. 依次类推

主从同时Down机情况:

1. 非计划性,不做考虑,一般也不会存在这种问题

2.、计划性重启,重启之前通过运维手段SAVE DUMP
主库数据;需要注意顺序:

1. 关闭其中一台机器上所有redis,是得master全部切到另外一台机器(多实例部署,单机上既有主又有从的情况);并关闭机器

2. 依次dump主上redis服务

3. 关闭主

4. 启动主,并等待数据load完毕

5. 启动从

6.删除DUMP
文件(避免重启加载慢)

(2)使用Twemproxy
实现集群方案

由twitter开源的c版本proxy,同时支持memcached和redis,目前最新版本为:0.2.4,持续开发中;https://github.com/twitter/twemproxy
.twitter用它主要减少前端与缓存服务间网络连接数。

特点:快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash
分片算法。

这里使用keepalived实现高可用主备方案,解决proxy单点问题;

优点:

1. 对于客户端而言,redis集群是透明的,客户端简单,遍于动态扩容

2. Proxy为单点、处理一致性hash时,集群节点可用性检测不存在脑裂问题

3. 高性能,CPU密集型,而redis节点集群多CPU资源冗余,可部署在redis节点集群上,不需要额外设备

4.3Memcache与Redis的比较

(1)数据结构:Memcache只支持key
value存储方式,Redis支持更多的数据类型,比如Key value,hash,list,set,zset;

(2)多线程:Memcache支持多线程,redis支持单线程;CPU利用方面Memcache优于redis;

(3)持久化:Memcache不支持持久化,Redis支持持久化;

(4)内存利用率:memcache高,redis低(采用压缩的情况下比memcache高);

(5)过期策略:memcache过期后,不删除缓存,会导致下次取数据数据的问题,Redis有专门线程,清除缓存数据;

五、本地缓存

本地缓存是指应用内部的缓存,标准的分布式系统,一般有多级缓存构成。本地缓存是离应用最近的缓存,一般可以将数据缓存到硬盘或内存。

3.1硬盘缓存

将数据缓存到硬盘到,读取时从硬盘读取。原理是直接读取本机文件,减少了网络传输消耗,比通过网络读取数据库速度更快。可以应用在对速度要求不是很高,但需要大量缓存存储的场景。

3.2 内存缓存

直接将数据存储到本机内存中,通过程序直接维护缓存对象,是访问速度最快的方式。

六、缓存架构示例

职责划分:

? CDN:存放HTML,CSS,JS等静态资源;

? 反向代理:动静分离,只缓存用户请求的静态资源;

? 分布式缓存:缓存数据库中的热点数据;

? 本地缓存:缓存应用字典等常用数据;

请求过程:

(1) 浏览器向客户端发起请求,如果CDN有缓存则直接返回;

(2) 如果CDN无缓存,则访问反向代理服务器;

(3) 如果反向代理服务器有缓存则直接返回;

(4) 如果反向代理服务器无缓存或动态请求,则访问应用服务器;

(5) 应用服务器访问本地缓存;如果有缓存,则返回代理服务器,并缓存数据;(动态请求不缓存)

(6) 如果本地缓存无数据,则读取分布式缓存;并返回应用服务器;应用服务器将数据缓存到本地缓存(部分);

(7) 如果分布式缓存无数据,则应用程序读取数据库数据,并放入分布式缓存;

七、参考资料

以下是本次分享参考的资料和推荐大家参考的资料。

7.1 CND资料

淘宝CDN系统架构:

http://blog.sina.com.cn/s/blog_4adf62ab0100tjld.html

天猫浏览型应用的CDN静态化架构演变【经典】

http://kb.cnblogs.com/page/199235/

ChinaCache CDN简介

http://wenku.baidu.com/link?url=oAT72EEemiRnH2Iy2Bg4phHXsRmSlN_WHd4jH7kiDb4TqYMIyCR3v7oUhKMj9GqN7W1qwu1K4tQNyD6NKtuQ7o7aT3JIujcd_QjRf34BtKO

7.2反向代理资料

squid反向代理:http://my.oschina.net/u/267384/blog/173149

7.3分布式缓存资料

Memcache知识点梳理:http://369369.blog.51cto.com/319630/833234/

memcache学习总结-wish

http://wenku.baidu.com/link?url=Qx4JYNgBJN0pqREImt1mZr625sj03AJoCWsIwDZlFQfi1iyejCb0feqG0gov3FLcrtEioJ3fU-4zj0H6VKPXWONYVZaAyX-HPWXDbRxyqF7

memcache 分布式,算法实现

http://1006836709.iteye.com/blog/1997381

分析Redis架构设计

http://blog.csdn.net/a600423444/article/details/8944601

Redis 集群方案:http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html

Redis常用数据类型:http://blog.sina.com.cn/s/blog_7f37ddde0101021q.html

原文地址:https://www.cnblogs.com/fengff/p/9415757.html

时间: 2024-10-09 17:49:54

分布式架构系列:缓存的相关文章

大神必修课系列之java 分布式架构的原理解

分布式术语 1.1. 异常 服务器宕机 内存错误.服务器停电等都会导致服务器宕机,此时节点无法正常工作,称为不可用. 服务器宕机会导致节点失去所有内存信息,因此需要将内存信息保存到持久化介质上. 网络异常 有一种特殊的网络异常称为--网络分区 ,即集群的所有节点被划分为多个区域,每个区域内部可以通信,但是区域之间无法通信. 磁盘故障 磁盘故障是一种发生概率很高的异常. 使用冗余机制,将数据存储到多台服务器. 1.2. 超时 在分布式系统中,一个请求除了成功和失败两种状态,还存在着超时状态. 可以

大神必修课系列之java 分布式架构的原理解析

分布式术语 1.1. 异常 服务器宕机 内存错误.服务器停电等都会导致服务器宕机,此时节点无法正常工作,称为不可用. 服务器宕机会导致节点失去所有内存信息,因此需要将内存信息保存到持久化介质上. 网络异常 有一种特殊的网络异常称为--网络分区 ,即集群的所有节点被划分为多个区域,每个区域内部可以通信,但是区域之间无法通信. 磁盘故障 磁盘故障是一种发生概率很高的异常. 使用冗余机制,将数据存储到多台服务器. 1.2. 超时 在分布式系统中,一个请求除了成功和失败两种状态,还存在着超时状态. 可以

大型网站架构系列:分布式消息队列(一) (转)

以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统). 本次分享大纲 消息队列概述 消息队列应用场景 消息中间件示例 JMS消息服务(见第二篇:大型网站架构系列:分布式消息队列(二)) 常用消息队列(见第二篇:大型网站架构系列:分布式消息队列(二)) 参考(推荐)资料(见第二篇:大型网站架构系列:分布式消息队列(二)) 本次分享总结(见第二篇:大型网站架构系列:分布式消息队列(二)) 一.消息队列概述 消息队列中间件是分布式系统中重要的组件,主要

大型网站架构系列:分布式消息队列(二)

本文是大型网站架构系列:消息队列(二),主要分享JMS消息服务,常用消息中间件(Active MQ,Rabbit MQ,Zero MQ,Kafka).[第二篇的内容大部分为网络资源的整理和汇总,供大家学习总结使用,最后有文章来源] 本次分享大纲 消息队列概述(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息队列应用场景(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息中间件示例(见第一篇:大型网站架构系列:分布式消息队列(一)) JMS消息服务 常用消息队列 参考(推荐)资料 本

大型网站架构系列:分布式消息队列(一)(转)

大型网站架构系列:分布式消息队列(一) 以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统). 本次分享大纲 消息队列概述 消息队列应用场景 消息中间件示例 JMS消息服务(见第二篇:大型网站架构系列:分布式消息队列(二)) 常用消息队列(见第二篇:大型网站架构系列:分布式消息队列(二)) 参考(推荐)资料(见第二篇:大型网站架构系列:分布式消息队列(二)) 本次分享总结(见第二篇:大型网站架构系列:分布式消息队列(二)) 一.消息队列概述 消息

大型网站架构系列:电商网站架构案例(3)

本文章是电商网站架构案例的第三篇,主要介绍数据库集群,读写分离,分库分表,服务化,消息队列的使用,以及本电商案例的架构总结. 6.5数据库集群(读写分离,分库分表) 大型网站需要存储海量的数据,为达到海量数据存储,高可用,高性能一般采用冗余的方式进行系统设计.一般有两种方式读写分离和分库分表. 读写分离:一般解决读比例远大于写比例的场景,可采用一主一备,一主多备或多主多备方式. 本案例在业务拆分的基础上,结合分库分表和读写分离.如下图: (1)       业务拆分后:每个子系统需要单独的库:

(转)大型网站架构系列:电商网站架构案例(1)

大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标). 根据实际需要,进行改造,扩展,支持千万PV,是没问题的. 本次分享大纲 电商案例的原因 电商网站需求 网站初级架构 系统容量估算 网站架构分析 网站架构优化 架构总结 电商网站案例,一共有三篇本篇主要说明网站的需求,网站初始架构,系统容量估算方法. 一.电商

大型网站架构系列:20本技术书籍推荐

学习是技术人员成长的基础,本次分享20本技术方面的书籍,这些书不是每一本都是经典,但是每一本都有其特点.以下20本大部分本人都看过,因此推荐给大家.(本次推荐的20本只是一个参考,比如像Head First,Java编程思想等经典书籍是大家都知道,因此不在推荐之列) 本次分享大纲 大型网站架构系列 分布式系统系列 BAT技术文学系列 架构设计系列 本次分享总结 一.大型网站架构系列 第一本:<大型网站技术架构:核心原理与案例分析> 这是本算是国内大型网站架构的经典之作,由阿里人李智慧创作,听名

大型网站架构系列:电商网站架构案例(1)

大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标). 根据实际需要,进行改造,扩展,支持千万PV,是没问题的. 本次分享大纲 电商案例的原因 电商网站需求 网站初级架构 系统容量估算 网站架构分析 网站架构优化 架构总结 电商网站案例,一共有三篇本篇主要说明网站的需求,网站初始架构,系统容量估算方法. 一.电商