zoukankan      html  css  js  c++  java
  • Memcache介绍

    面临的问题

        

        对于高并发高訪问的 Web应用程序来说。数据库存取瓶颈一直是个令人头疼的问题。

    特别当你的程序架构还是建立在单数据库模式,而一个数据池连接数峰值已经达到500的时候,那你的程序执行离崩溃的边缘也不远了。非常多小站点的开发者一開始都将注意力放在了产品需求设计上。却忽视了程序总体性能,可扩展性等方面的考虑。结果眼看着訪问量一天天往上爬,可突然发现有一天站点由于訪问量过大而崩溃了,到时候哭都来不及。所以我们一定要未雨绸缪,在数据库还没罢工前,想方设法给它减负。这也是这篇文章的主要议题。

        大家都知道,当有一个request过来后,webserver交给appserver。app处理并从db中存取相关数据,但db存取的花费是相当高昂的。特别是每次都取同样的数据,等于是让数据库每次都在做高耗费的无用功,数据库假设会说话。肯定会发牢骚,你都问了这么多遍了,难道还记不住吗?是啊。假设 app拿到第一次数据并存到内存里,下次读取时直接从内存里读取。而不用麻烦数据库。这样不就给数据库减负了?并且从内存取数据必定要比从数据库媒介取快非常多倍。反而提升了应用程序的性能。


    因此,我们能够在web/app层与db层之间加一层cache层


    主要目的:

    1. 降低数据库读取负担;

    2. 提高数据读取速度。

    并且,cache存取的媒介是内存。而一台server的内存容量一般都是有限制的,不像硬盘容量能够做到TB级别。所以,能够考虑採用分布式的cache层,这样更易于破除内存容量的限制,同一时候又添加了灵活性。


    Memcached 介绍


        Memcached 是开源的分布式cache系统,如今非常多的大型web应用程序包含 facebook,youtube,wikipedia。yahoo等等都在使用memcached来支持他们每天数亿级的页面訪问。

    通过把cache层与他们的web架构集成。他们的应用程序在提高了性能的同一时候。还大大降低了数据库的负载。 详细的memcached资料大家能够直接从它的官方站点[1]上得到。

    这里我就简单给大家介绍一下memcached的工作原理:


        Memcached处理的原子是每个(key,value)对(下面简称kv对),key会通过一个hash算法转化成hash-key,便于查找、对照以及做到尽可能的散列。同一时候,memcached用的是一个二级散列。通过一张大hash表来维护。
        Memcached 有两个核心组件组成:服务端(ms)和client(mc),在一个memcached的查询中,mc先通过计算key的hash值来确定kv对所处在的ms位置。当ms确定后,client就会发送一个查询请求给相应的ms,让它来查找确切的数据。由于这之间没有交互以及多播协议,所以 memcached交互带给网络的影响是最小化的。


    举例说明:考虑下面这个场景,有三个mc各自是X。Y,Z,还有三个ms各自是A,B,C:


        设置kv对 X想设置key=”foo”,value=”seattle” X拿到ms列表,并对key做hash转化。依据hash值确定kv对所存的ms位置 B被选中了 X连接上B,B收到请求,把(key=”foo”,value=”seattle”)存了起来
    获取kv对 Z想得到key=”foo”的value Z用同样的hash算法算出hash值,并确定key=”foo”的值存在B上 Z连接上B。并从B那边得到value=”seattle” 其它不论什么从X,Y,Z的想得到key=”foo”的值的请求都会发向B。



    查看全文

  • 相关阅读:
    三方登录微博url接口
    微博三方登录流程 (原理)
    celery配置与基本使用
    spring 验证框架
    IDEA 插件整理
    spring security笔记 默认登陆页面源码
    EXTJS7 自定义日期时间选择输入框
    EXTJS7 combobox本地模式 动态修改选项
    EXTJS7 combobox 下拉加载数据源码
    nginx 反向代理端口号丢失处理
  • 原文地址:https://www.cnblogs.com/wzjhoutai/p/7210855.html
Copyright © 2011-2022 走看看