淘宝客网站架构设计方案

转载 2013年12月02日 13:29:21

做一个淘宝客网站所需要的API,TOP几乎没有任何权限限制,唯一困扰各位淘客的应该就是流量了。以下详细讲解了四个案例,循序渐进,最终提供一个给各位淘客参考的网站架构,来解决这个流量超限的问题。仅针对淘宝客网站初学者参考,适合对淘宝客网站开发有一定了解的人。

  • 案例一:无缓存实时架构

这是一个最简单的模型。用户在访问网站的时候,程序接受用户访问请求后直接通过API获取数据,再显示在网页上。

优点:数据的实时获取

缺点:

1.网站页面加载的速度慢

2.网站访问量大的时候造成API次数超过限制,导致网站挂掉

3.淘宝API服务器发生故障或维护,导致网站挂掉

  • 案例二:文件缓存

这个案例中以文件的形式作为缓存,通过API取到数据序列化后并将序列化之后的数据存入文件中,一般以json的方式存储,也有的php程序中采用数组来存储。

优点:淘宝API服务器发生故障或维护时,保证了网站的正常使用

缺点:

1.页面显示速度慢,主要是在用户访问页面的时候触发API请求的

2.网站访问量大的时候造成API次数超过限制,导致网站挂掉

  • 案例三:使用memcached作为缓存

这个方案中加入了缓存判断,程序首先从memcached取缓存中的数据,如果数据失效或者过期的话,即没有命中,那么程序就通过API去请求数据,取到数据后更新缓存,同时返回数据。如果数据存在且在有效期内的话,那么将直接返回缓存中的数据,这比用文件缓存速度快得多。硬盘快不过内存就是这个道理。

优点:页面显示速度快,在API服务器正常的时候还能自动更新缓存数据

缺点:

1. 
缓存命中率的提高有难度,有过mm集群开发经验的同学应该感受到了

2. 
网站访问量大的时候造成API次数超过限制网站挂掉

3. 
服务器重启后缓存数据全部丢失(单机的情况下)

  • 案例四:缓存+持久层结合架构

在案例三的基础上引入一个持久存储层MySQL,这样子可以避免重启,淘宝API服务器异常的情况。

优点:有持久层存储,数据不丢失。 服务器重启,淘宝API服务器维护等各种伤不起都是浮云。

缺点:

1. 
用不多久,你会看着数据库中那高达几十GB的表而疯掉

2. 
网站访问量大的时候造成API次数超过限制,导致网站挂掉

3. 数据迅速递增,查询相当缓慢

综合上面几个典型的案例,我们不难看出淘宝客网站在架构方面或多或少存在的问题:

1.数据实时性问题

2.读取数据的速度问题(网站页面显示速度)

3.缓存失效问题

4.API次数超过限制问题

  • 在以上4个问题中,尤其以API次数超过限制问题为主,如何解决呢?看下图架构

  • 该架构中,引入开源nosql产品 
    redis。在数据每秒都发生变化的时候,关系性数据库mysql 等扛不住递增的海量新数据,而redis等可以,为什么? Key! 
    大多的时候我们不用缓存淘宝的所有数据,一个好的key设计比什么都强。

    在大多数应用中可以使用提交的参数md5的值为key。

    获取key的方法详解:

    如调用taobao.user.get接口,

    所有入参有method=taobao.user.get,session=xxx,timestamp=xxxx,format=json,app_key=123456,v=2.0,sign=ERJLJGDSFSDFSD,sign_method=md5,fields=nick,sex,nick=淘宝帐号。

    由于timestamp,sign这两个参数几乎每时每刻都在变化,而session每次授权都在变化,所以先排除session,timestamp,sign这三个参数。再按照首字母升级排列:

    app_key=12345

    fields=nick,sex

    format=json

    method=taobao.user.get

    nick=淘宝账号

    sign_method=md5

    v=2.0

    拼接字符串为:app_key12345fieldsnick,sexformatjsonmethodtaobao.user.getnick淘宝账号sign_methodmd5v2.0

    key=md5(app_key12345fieldsnick,sexformatjsonmethodtaobao.user.getnick淘宝账号sign_methodmd5v2.0)

    可以使用这样的key为32位。新的数据只能刷新缓存值,增加的缓存能有多少。

    taobao.taobaoke.items.get你能取多少页?按照不同的排序有多少?

    具体的实现思路见上面流程图。其中网关实际上就是自己搭建一个读数据的接口,所有数据都从这里单点读取,由它来

    分发。网关的数据来源有:memcached缓存, Redis数据库。 
    在memcached缓存数据失效或者没有命中的时候通过API 取数

    据,这里的API不是直接去淘宝取数据,引入了自己设定的每分钟频率,比如100次/分钟,超过的时候直接去redis 取

    数据返回,当然这里的redis最好不要设置比较长的refresh 
    time,一般5~10分钟就可以。

    淘宝客网站的架构中缓存是非常重要的一个环节,控制不好就会带来各种困扰。关键点是在部署缓存和缓存key的设计

    上。

    优点:自己搭建数据来源网关, 
    内存缓存与永久存储层的合理搭配。

    需要了解的知识:

    1. 
    Memcache合理部署

    2. 
    redis 的基本功能及安装、维护。

    建议:这里的memcached 
    部署一个缓存集群,在单点失效的情况下,数据不丢失,新机器恢复的时候自动

    从backup机器里恢复缓存。 
    Redis部署两台,一主一从。

关于大淘客CMS免费二次开发分享的曝光

作者只是一位大三的IT从业者,对于同行的行为我没有权利去曝光,刚刚我用昵称“无法”在群里提出问题时,我就知道有问题,一句话解释所有“天下没有免费的午餐”,就像你一开始领着免费的优惠卷开心的不得了,谁知...
  • u014417566
  • u014417566
  • 2017年10月16日 17:30
  • 1357

手机淘宝的客户端架构探索之路

主讲人:冯森林(无锋/ Oasis Feng)产品挑战淘宝手机客户端承载并整合多样化的业务生态。 淘宝手机客户端生态是非常多样的,有IM形态的旺信,购物形态的天猫,工具形态的充值,教育形态的淘宝大学...
  • licaomengRICE
  • licaomengRICE
  • 2015年10月19日 18:40
  • 7439

淘宝,京东,苏宁易购技术架构(路线)分析和比较

最近因为参与项目的关系,对淘宝,京东,苏宁易购三家网站系统构架做了肤浅的研究,做了几张图,放在下面,给需要的同学,欢迎大家讨论指正,邮件可发至我的邮箱:fengqiang # gmail.com...
  • jhzyz
  • jhzyz
  • 2014年06月23日 17:44
  • 37113

淘宝Diamond架构分析

花了两天的时间研究了下Diamond,因为写得比较急,而且并没有使用过,只是单纯的做逆向建模,所以难免会有细节缺失,后面会时不时过来看看,然后做些补充。背景知识比较早的时候,应用一般都是单体的,配置修...
  • szwandcj
  • szwandcj
  • 2016年04月16日 11:15
  • 8203

最全面的网站架构设计方案

  • 2012年12月11日 21:58
  • 4.89MB
  • 下载

前台门户网站架构设计方案

  • 2013年01月14日 16:49
  • 1.51MB
  • 下载

可扩展、高可用、负载均衡网站架构设计方案

  • 2008年07月25日 04:05
  • 148KB
  • 下载

高并发网站架构设计方案

  • 2015年02月27日 09:52
  • 32KB
  • 下载

可扩展、高可用、负载均衡网站架构设计方案

基本需求: 1、  高可用性:将停止服务时间降低到最低甚至是不间断服务 2、  可扩展性:随着访问的增加,系统具备良好的伸缩能力 3、  可视性:系统、服务的状态处于一个实时的监控之下 4、 ...
  • liaoyuanzi
  • liaoyuanzi
  • 2013年01月07日 22:33
  • 507

基于Java技术的大型网站架构设计方案

基于Java技术的大型网站架构设计方案 笑游江湖 发表于 2014-03-16 16:56:00 | 分类标签: 网站架构 JAVA 高并发 1、Web层 主体架构可以基于 Struts 1...
  • JackieLiuLixi
  • JackieLiuLixi
  • 2014年05月23日 17:24
  • 15310
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:淘宝客网站架构设计方案
举报原因:
原因补充:

(最多只允许输入30个字)