精华内容
下载资源
问答
  • 操作系统处理机管理

    千次阅读 2017-03-14 09:37:58
     在单道程序系统中,程序只能够顺序的执行,即两个程序只能等一个执行完再执行下一个。这样就使程序的执行具有三个特型:顺序性、封闭性和可再现性。而到了多道程序系统中,允许程序并发的执行(宏观并行,微观串行...

    处理机管理可归结为对进程的管理。

    为什么需要进程?

             在单道程序系统中,程序只能够顺序的执行,即两个程序只能等一个执行完再执行下一个。这样就使程序的执行具有三个特型:顺序性、封闭性和可再现性。而到了多道程序系统中,允许程序并发的执行(宏观并行,微观串行)。此时程序并发执行就具有了:间断性、失去封闭性和不可再现性。为了解决程序并发执行的问题,并且可以对并发执行的程序加以描述和控制,人们就引入了进程的概念。

    什么是进程?

             进程是程序的一次执行,是资源分配和调度的基本单位。进程 = 程序 + 数据 + 程序控制块(Process Control Block,PCB)。

             PCB是进程最重要的数据结构,是进程存在的唯一标识。PCB中记录了系统所需的,用于描述进程的当前情况一起管理进程运行的全部信息。OS通过PCB就能够很好的控制进程。PCB中的记录的内容大致为:进程标识符、处理机状态、进程调度信息、进程控制信息。

             进程的管理下面几个方面:

    • 进程控制
    • 进程同步
    • 进程通信
    • 进程调度      

    进程的状态

            就绪状态——进程所需要的资源都已经到位,只需要等待处理机调度

            运行状态——进程获得处理机,正在执行

            阻塞状态——进程等待某些事件的发生才能继续执行,所以不再占用处理机而转为阻塞状态

            进程的三态图和五态图如下:

                         

    进程控制

            进程的控制主要包括创建进程、撤销进程以及进程的状态转换。进程控制一般有OS的内核通过原语来实现。

            内核(Kernel):一些常驻内存,存在于紧靠硬件的软件层次中的模块的集合。例如中断处理程序、常用设备驱动程序及运行频率较高的模块(时钟管理、进程调度这些)。

            内核一般都包含了支撑功能(中断处理、时钟管理和原语操作)以及资源管理功能(进程、存储器和设备的管理)。

           原语——由若干条指令组成的,用于完成一定功能的一个过程。或者说是系统态下执行的某些具有特定功能的程序段。原语操作是一种“原子操作”,就是不可分的意思。即一个操作中的所有动作要么全做,要么全不做。

           阻塞和唤醒的原语分别是 block 和 wakeup。挂机和激活的原语是 suspend 和 active 。

    进程同步

          进程同步机制的主要任务,是对多个相关进程在执行次序上进行协调,是并发执行的进程能按一定的规则(或时序)共享系统资源,并能很好的相互合作,从而使程序的执行具有可再现性。

          进程之间的制约:

    •  直接制约——共享缓冲区   同步
    •  间接制约——互斥资源   互斥

          临界区:进程中访问临界资源的代码。

          进程必须互斥地进入自己的临界区,系统为此设置了专门的同步机构来协调。同步机制需要遵循十六字真言:空闲让进、忙则等待、有限等待、让权等待。

          1965年Dijkstra提出信号量(Semaphores)机制是一种卓有成效的进程同步工具,这个机制有几种发展产物。我们通常使用记录型信号量。

          记录型信号量只是在整形信号量的基础上增加了将进程阻塞和唤醒的操作,这样符合“让权等待”的规则。

          信号量S是一个表示资源数目的东西,只有在wait(S)和signal(S)这两个原子操作中才能够修改,这就保护了信号量不被其它地方随意改变。这两个操作又称为PV操作。

          P操作就相当于在访问资源之前,先对代表该资源的信号量进行判断,如果有就访问,没有的话该进程就被阻塞等待。

          V操作就是在访问资源之后,释放一个资源,并唤醒一个等待该资源的进程。


    信号量机制实现前驱图也经常考到,但很简单。对于前驱图中一个结点,有多少个箭头指向它,则在执行本身程序之前必须先进行多少次 P 操作来等待所有资源。有多少个箭头从它指出去,在本身程序执行后就要进行多少次 V 操作释放资源。

    信号量机制实现互斥:

          为临界资源设置一互斥信号量mutex,初始值为1。每个进程在进入临界区之前都要对该信号量进行P操作,判断mutex的值,如果为1则表示没有其它进程正在访问该资源,现在可以访问;如果为0则表示当前有进程在访问该资源必须等待。这就相当于用一个标识符给临界区上了锁,实现了互斥访问。

    信号量机制实现同步:

          两个进程共享缓冲池,想象生产者和消费者的问题。设缓冲池具有的可用空间为n,要为该缓冲池设置3个信号量,一个是互斥访问信号量S,初始值为1。一个是S1,初始值为n,表示缓冲池可用空间数。另一个是S2,初始值为0,表示缓冲池中已满空间数(相当于已有产品数)。在这个条件下:

         对于生产者进程,在将产品放入到缓冲池(访问)之前必须先对 S1 进行 P操作,判断 S1 的值,如果不为0,就对 S 执行 P操作,判断该缓冲区中是否有其它进程正在访问。如果为 0,则表示该缓冲区已满不能再放产品,生产者进程只能等待。只有这两个 P操作都通过了,生产者才能将产品放入缓冲池。然后对 S 进行 V操作,释放访问,再对 S2(是S2,不是S1,因为放了一个产品是要给S2加1)进行 V操作。

         对于消费者进程,在从缓冲池拿出产品(访问)之前必须现对 S2 进行 P操作,判断 S2 的值,如果不为0,就对 S 执行 P操作。如果为0,则表示缓冲区为空(没有产品),消费者进程必须等待。只有这两个 P操作都通过,生产者才能拿到产品。然后对 S 进行 V操作,表示自己不再访问临界区了。再对 S1 进行V操作。

    管程

         虽然信号量机制已经是一种方便又高效的进程同步机制,但每个访问临界区的进程必须自备PV操作,这就是大量同步操作分散在各个进程中,不利于系统的管理,也容易产生死锁。为了解决问题,又引进了一个新概念——管程。

         系统中的资源都可以用数据结构抽象地描述其资源特性,而忽略它们的内部结构和实现细节。因此,可以利用共享数据结构抽象地表示共享资源,并且将对该共享数据结构实施特定的操作定义为一组过程。简单理解,这个过程就是我们所说的管程。

         有了管程之后,进程对共享资源的访问,可以不用自备PV操作了。直接通过这一个过程就可以,这一个过程就包括了进程对资源的申请、请求和其它操作。而这个过程可以确保每次只让一个进程进入,实现了互斥。也达到了对共享资源的所有访问的统一管理。

         仔细想想,管程其实包含了面向对象的思想,将数据和操作都封装起来,隐藏实现细节。任何管程以外的过程都不能访问到里面的数据。进程也只需要调用管程中的方法就可实现对资源的访问。

    线程

          如果说进程的引入是为了解决程序并发执行的问题,那么线程的引入则是为了更好的提高程序并发执行的程度。

          因为进程本身是占有资源的,在进行进程调度时有很大的时空开销。所以再将进程分为更小的不带资源(占据很少量资源)的线程,然后以线程作为为调度和分配的基本单位来较小时空开销,提高并发程度。

    进程通信

          进程之间因为存在着互斥和同步的关系,所以进程之间肯定需要进行一定的信息交换。(没有沟通,怎么能懂别人想干什么呢,对吧)

          前面提到了信号量机制其实就是一种低级通信,因为每次只能告知另一个进程一个信息。比如说放了一个产品,而不能说放很多产品了。

          高级通信就是能够高效地传送大量数据,并且使用方便,对用户透明(系统隐藏了实现进程通信的具体细节)。

    一个很关键的概念:在操作系统中,“透明” 一词指某种东西实际存在,但从某个角度看好像没有。就是对应用人员来说不可见(你只能按它说的做,但不能直接控制)。

          高级通信包括:

    • 共享存储器系统
    • 管道(pipe)通信系统
    • 消息传递系统——不借助任何共享存储区,直接以格式化的消息为单位,将通讯数据封装在消息中,并利用OS提供的通信命令(原语)在进程之间进行消息传递。这个方式隐藏了通信细节,对用户透明化,使用简单。计算机网络中就采用了这种方式,不过不叫消息,而叫报文。该方式又可分成直接通信方式(发送进程直接利用发送原语将消息发送给接收进程)和间接通信方式(发送和接收进程通过共享中间实体(邮箱)来进行消息的发送和接收)
    • 客户/服务器系统——主要用于网络环境下,主要技术有:套接字(Socket,一个通信标识类型的数据结构,通过这个套接字,进程就能知道通信目的地址、使用的端口号、传输层协议、进程所在网址等信息),远程过程调用(Remote Procedure Call)和远程方法调用(和过程类似,不过在面向对象中叫方法)。

    进程调度

           三级调度的概念:

    1. 高级调度——又称作业调度(将作业从后备队列调入就绪队列,也就是从外存调入内存)
    2. 中级调度——又称兑换调度(类似于挂起和激活)
    3. 低级调度——又称进程调度

           调度算法:先来先服务、时间片轮转法、优先级调度、多级反馈队列调度(具体算法思想就不再赘述)

           死锁:一组进程中的每个进程都在等待着只能由改组进程才能引发的事件。

           死锁必要条件:互斥条件、请求和保持条件(就是既占有资源,又请求新资源)、不可抢占条件,环路条件。

           死锁预防:通过破环四个必要条件中的一个或几个。一次性分配法(破坏请求和保持条件)、有序资源分配法(破坏环路条件)

           死锁避免:银行家算法,就是对每一次分配资源都要判断是否是安全状态,安全才分配,不安全则不分配,开销很大。

           死锁检测:看图法

           死锁解除:抢占资源、终止进程。

    展开全文
  • 下面就结合淘宝目前的一些底层技术框架以及自己的一些感触来说说如何构建一个可 伸缩,高性能,高可用性的分布式互联网应用。 时间过得很快,来淘宝已经两个月了,这两个月的时间里,自己也感受颇深。下面就结合...
    下面就结合淘宝目前的一些底层技术框架以及自己的一些感触来说说如何构建一个可 
    伸缩,高性能,高可用性的分布式互联网应用。
    

    时间过得很快,来淘宝已经两个月了,在这两个月的时间里,自己也感受颇深。下面就结合淘宝目前的一些底层技术框架以及自己的一些感触来说说如何构建一个可 伸缩,高性能,高可用性的分布式互联网应用。

    一 应用无状态(淘宝session框架)

    俗话说,一个系 统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢?咱们试想一下,假如我们在session中保存了大量与客户端的状态信 息的话,那么当保存状态信息的server宕机的时候,我们怎么办?通常来说,我们都是通过集群来解决这个问题,而通常所说的集群,不仅有负载均衡,更重要的是要有失效恢复failover,比如tomcat采 用的集群节点广播复制,jboss采 用的配对复制等session状 态复制策略,但是集群中的状态恢复也有其缺点,那就是严重影响了系统的伸缩性,系统不能通过增加更多的机器来达到良好的水平伸缩,因为集群节点间session的 通信会随着节点的增多而开销增大,因此要想做到应用本身的伸缩性,我们需要保证应用的无状态性,这样集群中的各个节点来说都是相同的,从而是的系统更好的水平伸缩。

    OK,上面说了无状态的重要性,那么具体如何实现无状态呢?此时一个session框架就会发挥作用了。幸运的是淘 宝已经具有了此类框架。淘宝的session框架采用的是client cookie实现,主要将状态保存到了cookie里 面,这样就使得应用节点本身不需要保存任何状态信息,这样在系统用户变多的时候,就可以通过增加更多的应用节点来达到水平扩展的目的.但 是采用客户端cookie的 方式来保存状态也会遇到限制,比如每个cookie一般不能超过4K的大小,同时很多浏览器都限制一个站点最多保存20个cookie.淘 宝cookie框 架采用的是“多值cookie”, 就是一个组合键对应多个cookie的 值,这样不仅可以防止cookie数 量超过20, 同时还节省了cookie存 储有效信息的空间,因为默认每个cookie都会有大约50个字节的元信息来描述cookie。

    除了淘宝目前的session框 架的实现方式以外,其实集中式session管理来完成,说具体点就是多个无状态的应用节点连接一个session 服 务器,session服 务器将session保 存到缓存中,session服 务器后端再配有底层持久性数据源,比如数据库,文件系统等等。

    二 有效使用缓存(Tair)

    做互联网应用的兄弟应该都清楚,缓存对于一个互联网应用是多么的重要,从浏览器缓存,反向代理缓存,页面缓存,局部页面缓存,对象缓存等等都是缓存应用的场景。

    一 般来说缓存根据与应用程序的远近程度不同可以分为:local cache 和 remote cache。 一般系统中要么采用local cache,要么采用remote cache,两者混合使用的话对于local cache和remote cache的数据一致性处理会变 大比较麻烦.

    在大部分情况下,我 们所说到的缓存都是读缓存,缓存还有另外一个类型:写缓存. 对 于一些读写比不高,同时对数据安全性需求不高的数据,我们可以将其缓存起来从而减少对底层数据库的访问,比如 统计商品的访问次数,统 计API的 调用量等等,可 以采用先写内存缓存然后延迟持久化到数据库,这样可以大大减少对数据库的写压力。

    OK,我以店铺线的系统为例,在用户浏览店铺的时候,比如店铺介绍,店铺交流区页面,店铺服务条款页面,店铺试衣间页面,以及店铺内搜索界面这些界面更新不是非常频繁,因此适合放到缓存中,这样可以大大减低DB的负载。另外宝贝详情页面相对也更新比较 少,因此也适合放到缓存中来减低DB负载。

    三 应用拆分(HSF)

    首先,在说明应用拆分之前,我们先来回顾一下一个系统从小变大的过程中遇到的一些问题,通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。

    系统刚上线初期,用户数并不多,所有的逻辑也许都是放在一个系统中的,所有逻辑跑到一个进程或者一个应用当中,这个时候因为比较用户少,系统访问量低,因此将全部的逻辑都放在一个应用未尝不可。但是,兄弟们都清楚,好景不长,随着系统用户的不断增加,系统的访问压力越来越多,同时随着系统发展,为了满足用户 的需求,原有的系统需要增加新的功能进来,系统变得越来越复杂的时候,我们会发现系统变得越来越难维护,难扩展,同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢?明智的办法就是拆分(这也算是一种解耦),我们需要将原来的系统根据一定的标准,比如业务相关性等分为不同的子系统, 不同的系统负责不同的功能,这样切分以后,我们可以对单独的子系统进行扩展和维护,从而提高系统的扩展性和可维护性,同时我们系统的水平伸缩性scale out大 大的提升了,因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统,而不会像拆分以前,每次系统压力变大的时候,我们都需要对整个大系统进行伸缩,而这样的成本是比较大的,另外经过切分,子系统与子系统之间的耦合减低了,当某个子系统暂时不可用的时候,整体系统还是可用的,从而整 体系统的可用性也大大增强了。

    因此一个大型的互联网应用,肯定是要经过拆分,因为只有拆分了,系统的扩展性,维护性,伸缩性,可用性才会变的更好。但是拆分也给系统带来了问题,就是子系统之间如何通信的问题,而具体的通信方式有哪些呢?一般有同步通信和异步通信,这里我们首先来说下同步通信,下面的主题“消息系 统”会说到异步通信。既然需要通信,这个时候一个高性能的远程调用框架就显得非常总要啦,因此咱们淘宝也有了自己的HSF框 架。

    上 面所说的都是拆分的好处,但是拆分以后必然的也会带来新的问题,除了刚才说的子系统通信问题外,最值得关注的问题就是系统之间的依赖关系,因为系统多了,系统的依赖关系就会变得复杂,此时就需要更好的去关注拆分标准,比如能否将一些有依赖的系统进行垂直化,使得这些系统的功能尽量的垂直,这也是目前淘宝正 在做的系统垂直化,同时一定要注意系统之间的循环依赖,如果出现循环依赖一定要小心,因为这可能导致系统连锁启动失败。

    OK,既然明白了拆分的重要性,我们看看随着淘宝的发展,淘宝本身是如何拆分系统的。

    首先我们来看以下这个图:(作者图片已无法打开,请见谅)

    从上面的图可以看出淘宝系统的一个演变过程,在这个演变的过程中,我们所说的拆分就出现V2.2和V3.0之 间。在V2.2版 本中,淘宝几乎所有的逻辑都放在(Denali)系统中,这样导致的问题就是系统扩展和修改非常麻烦,并且更加致命的是随着淘宝业务量的增加,如果按照V2.2的架构已经没有办法支撑以后淘宝的快速发展,因此大家决定对整个系统进行拆分,最 终V3.0版本的淘宝系统架构图如下:(作者图片已无法打开,请见谅)

    从上图可以看出V3.0版 本的系统对整个系统进行了水平和垂直两个方向的拆分,水平方向上,按照功能分为交易,评价,用户,商品等系统,同样垂直方向上,划分为业务系统,核心业务系统以及以及基础服务,这样以来,各个系统都可以独立维护和独立的进行水平伸缩,比如交易系统可以在不影响其它系统的情况下独立的进行水平伸缩以及功能扩展。

    从上面可以看出,一个大型系统要想变得可维护,可扩展,可伸缩,我们必须的对它进行拆分,拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题,关于通信方面,淘宝目前独立开发了自己的高性 能服务框架HSF, 此框架主要解决了淘宝目前所有子系统之间的同步和异步通信(目前HSF主要用于同步场合,FutureTask方 式的调用场景还比较少)。至于系统间的依赖管理,目前淘宝还做的不够好,这应该也是我们以后努力解决的问题。

    四 数据库拆分(TDDL)

    在前面“应用拆分”主题中,我们提到了一个大型互联网应用需要进行良好的拆分,而那里我们仅仅说了”应用级别”的拆 分,其实我们的互联网应用除了应用级别的拆分以外,还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统,通常就是所说的RDBMS进 行拆分。

    好了,确定了这个小节的主题之后,我们回顾一下,一个互联网应用从小变大的过程中遇到的一些问题,通过遇到的问题来引出我们拆分RDBMS的 重要性。

    系 统刚开始的时候,因为系统刚上线,用户不多,那个时候,所有的数据都放在了同一个数据库中,这个时候因为用户少压力小,一个数据库完全可以应付的了,但是随着运营那些哥们辛苦的呐喊和拼命的推广以后,突然有一天发现,oh,god,用户数量突然变多了起来,随之而 来的就是数据库这哥们受不了,它终于在某一天大家都和惬意的时候挂掉啦。此时,咱们搞技术的哥们,就去看看究竟是啥原因,我们查了查以后,发现原来是数据库读取压力太大了,此时咱们都清楚是到了读写分离的时候,这个时候我们会配置一个server为master节 点,然后配几个salve节 点,这样以来通过读写分离,使得读取数据的压力分摊到了不同的salve节点上面,系统终于又恢复了正常,开始正常运行了。但是好景还是不长,有一天我们发现master这哥们撑不住了,它负载老高了,汗 流浃背,随时都有翘掉的风险,这个时候就需要咱们垂直分区啦(也就是所谓的分库),比如将商品信息,用户信息,交易信息分别存储到不同的数据库中,同时还可以针对商品信息的库采用master,salve模式,OK, 通过分库以后,各个按照功能拆分的数据库写压力被分担到了不同的server上面,这样数据库的压力终于有恢复到正常状态。但是是不是这样,我们就可以高枕无忧了呢?NO,这个NO, 不是我说的,是前辈们通过经验总结出来的,随着用户量的不断增加,你会发现系统中的某些表会变的异常庞大,比如好友关系表,店铺的参数配置表等,这个时候无论是写入还是读取这些表的数据,对数据库来说都是一个很耗费精力的事情,因此此时就需要我们进行“水平分区”了(这就是俗话说的分表,或者说sharding).

    OK,上 面说了一大堆,无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”,一个大型的互联网 应用必然会经过一个从单一DB server,到Master/salve(主/从),再到垂直分区(分库),然后再到水平分区(分表,sharding)的过程,而在这个过程中,Master/salve 以 及垂直分区相对比较容易,对应用的影响也不是很大,但是分表会引起一些棘手的问题,比如不能跨越多个分区join查 询数据,如何平衡各个shards的 负载等等,这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响,使得底层数据的访问对应用透明化。

    拿淘宝目前的情况来说,淘宝目前也正在从昂贵的高端存储(小型机+ORACLE)切换到MYSQL,切 换到MYSQL以 后,势必会遇到垂直分区(分库)以及水平分区(Sharding)的问题,因此目前淘宝根据自 己的业务特点也开发了自己的TDDL框架,此框架主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制

    分库降低了单点机器的负载;分表,提高了数据操作的效率,尤其是Write操作的效率

    五 异步通信(Notify)

    在”远 程调用框架”的 介绍中,我 们说了一个大型的系统为了扩展性和伸缩性方面的需求,肯定是要进行拆分,但是 拆分了以后,子 系统之间如何通信就成了我们首要的问题,在”远程调用框架”小节 中,我 们说了同步通信在一个大型分布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既 然说到了异步通信,那 么”消 息中间件”就 要登场了,采 用异步通信这其实也是关系到系统的伸缩性,以及最大化的对各个子系统进行解耦.

    说 到异步通信,我们需要关注的一点是这里的异步一定是根据业务特点来的,一定是针对业务的异步,通常适合异步的场合是一些松耦合的通信场合,而对于本身业务上关联度比较大的业务系统之间,我们还是要采用同步通信比较靠谱。

    OK,那 么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想,假如系统有A和B两个 子系统构成,假如A和B是 同步通信的话,那么要想使得系统整体伸缩性提高必须同时对A和B进行 伸缩,这就影响了对整个系统进行scale out.其次,同步调用还会影响到可用性,从数学推理的角度来说,A同 步调用B, 如果A可 用,那么B可 用,逆否命题就是如果B不 可用,那么A也 不可用,这将大大影响到系统可用性,再次,系统之间异步通信以后可以大大提高系统的响应时间,使得每个请求的响应时间变短,从而提高用户体验,因此异步在提高了系统的伸缩性以及可用性的同时,也大大的增强了请求的响应时间(当然了,请求的总体处理时间也许不会变少)。

    下面我们就以淘宝的业务来看看异步在淘宝的具体应用。交易系统会与很多其它的业务系统交互,如果在一次交易过程中采用同步调用的话,这就要求要向交易成功,必须依赖的所有系统都可用,而如果采用异步通信以后,交易系 统借助于消息中间件Notify和 其它的系统进行了解耦,这样以来当其它的系统不可用的时候,也不会影响到某此交易,从而提高了系统的可用性。

    最后,关于异步方面的讨论,我可以 推荐大家一些资源:

    1 . J2EE meets web2.0

    2. Ebay架构特点(HPTS 2009)

    六 非结构化数据存储 ( TFS,NOSQL)

    在 一个大型的互联网应用当中,我们会发现并不是所有的数据都是结构化的,比如一些配置文件,一个用户对应的动态,以及一次交易的快照等信息,这些信息一般不适合保存到RDBMS中, 它们更符合一种Key-value的 结构,另外还有一类数据,数据量非常的大,但是实时性要求不高,此时这些数据也需要通过另外的一种存储方式进行存储,另外一些静态文件,比如各个商品的图片,商品描述等信息,这些信息因为比较大,放入RDBMS会引起读取性能问题,从而影响到其它 的数据读取性能,因此这些信息也需要和其它信息分开存储,而一般的互联网应用系统都会选择把这些信息保存到分布式文件系统中,因此淘宝目前也开发了自己的分布式文件系统TFS,TFS目 前限制了文件大小为2M, 适合于一些小于2M数 据的存放。

    随 着互联网的发展,业界从08年 下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论,一致性,可用性和分区容错性3者 不能同时满足,最多只能同时满足两个,我们传统的关系数据采用了ACID的事务策略,而ACID的 事务策略更加讲究的是一种高一致性而降低了可用性的需求,但是互联网应用往往对可用性的要求要略高于一致性的需求,这个时候我们就需要避免采用数据的ACID事 务策略,转而采用BASE事 务策略,BASE事 务策略是基本可用性,事务软状态以及最终一致性的缩写,通过BASE事务策略,我们可以通过最终一致性来提升系统的可用性,这也是目前很多NOSQL产品所采用的策略,包括facebook 的cassandra,apache hbase,google bigtable等,这些产品非常适合一些非结构化的数据,比如key-value形 式的数据存储,并且这些产品有个很好的优点就是水平伸缩性。目前淘宝也在研究和使用一些成熟的NOSQL产品。

    七 监控、预警系统

    对于大型的系统 来说,唯一可靠的就是系统的各个部分是不可靠。

    因 为一个大型的分布式系统中势必会涉及到各种各样的设备,比如网络交换机,普通PC机,各种型号的网卡,硬盘,内存等等,而这些东东都在数量非常多的时候,出现错误的概率也会变大,因此我们需要时时刻刻监控系统的状态,而监控也有粒度的粗细之分,粒度粗一点的话,我们需要对整个 应用系统进行监控,比如目前的系统网络流量是多少,内存利用率是多少,IO,CPU的 负载是多少,服务的访问压力是多少,服务的响应时间是多少等这一系列的监控,而细粒度一点的话,我们就需对比如应用中的某个功能,某个URL的 访问量是多,每个页面的PV是 多少,页面每天占用的带宽是多少,页面渲染时间是多少,静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。因此一个监控系统就变得必不可少了。

    前 面说了一个监控系统的重要性,有了监控系统以后,更重要的是要和预警系统结合起来,比如当某个页面访问量增多的时候,系统能自动预警,某台Server的CPU和 内存占用率突然变大的时候,系统也能自动预警,当并发请求丢失严重的时候,系统也能自动预警等等,这样以来通过监控系统和预警系统的结合可以使得我们能快速响应系统出现的问题,提高系统的稳定性和可用性。

    八 配置统一管理

    一个大型的分布 式应用,一般都是有很多节点构成的,如果每次一个新的节点加入都要更改其它节点的配置,或者每次删除一个节点也要更改配置的话,这样不仅不利于系统的维护和管理,同时也更加容易引入错误。另外很多时候集群中的很多系统的配置都是一样的,如果不进行统一的配置管理,就需要再所有的系统上维护一份配置,这样会 造成配置的管理维护很麻烦,而通过一个统一的配置管理可以使得这些问题得到很好的解决,当有新的节点加入或者删除的时候,配置管理系统可以通知各个节点更新配置,从而达到所有节点的配置一致性,这样既方便也不会出错。

    展开全文
  • Java实现并发处理的方式

    千次阅读 2017-08-11 23:38:46
    并发处理的方式

    转载博客地址:http://blog.csdn.NET/zxl333/article/details/8454319

    转载博客地址:http://blog.csdn.net/zxl333/article/details/8685157

    转载博客地址:http://blog.csdn.net/jimmy609/article/details/37810591

    一个小型的网站,比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构、性能的要求都很简单,随着互联网业务的不断丰富,网站相关的技术经过这些年的发展,已经细分到很细的方方面面,尤其对于大型网站来说,所采用的技术更是涉及面非常广,从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态网站所能比拟的。

    大型网站,比如门户网站。在面对大量用户访问、高并发请求方面,基本的解决方案集中在这样几个环节:使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面,还没法根本解决大型网站面临的高负载和高并发问题。

    上面提供的几个解决思路在一定程度上也意味着更大的投入,并且这样的解决思路具备瓶颈,没有很好的扩展性,下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。

    1、HTML静态化

    其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。

    除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化,有更新的时候再重新静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。

    同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用html静态化来实现,比如论坛中论坛的公用设置信息,这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以考虑将这部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求。

    2、图片服务器分离

    大家知道,对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持,尽可能少的LoadModule,保证更高的系统消耗和执行效率。

    3、数据库集群和库表散列

    大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。

    在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。

    上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

    4、缓存

    缓存一词搞技术的都接触过,很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
    架构方面的缓存,对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力。
    网站程序开发方面的缓存,Linux上提供的Memory Cache是常用的缓存接口,可以在web开发中使用,比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享,一些大型社区使用了这样的架构。另外,在使用web语言开发的时候,各种语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块,Java就更多了,.net不是很熟悉,相信也肯定有。

    5、镜像

    镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异,比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点,数据进行定时更新或者实时更新。在镜像的细节技术方面,这里不阐述太深,有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路,比如linux上的rsync等工具。

    6、负载均衡

    负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

    负载均衡技术发展了多年,有很多专业的服务提供商和产品可以选择,我个人接触过一些解决方法,其中有两个架构可以给大家做参考。

    1)硬件四层交换

    第四层交换使用第三层和第四层信息包的报头信息,根据应用区间识别业务流,将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就象是虚IP,指向物理服务器。它传输的业务服从的协议多种多样,有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上,需要复杂的载量平衡算法。在IP世界,业务类型由终端TCP或UDP端口地址来决定,在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

    在硬件四层交换产品领域,有一些知名的产品可以选择,比如Alteon、F5等,这些产品很昂贵,但是物有所值,能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

    2)软件四层交换

    大家知道了硬件四层交换机的原理后,基于OSI模型来实现的软件四层交换也就应运而生,这样的解决方案实现的原理一致,不过性能稍差。但是满足一定量的压力还是游刃有余的,有人说软件实现方式其实更灵活,处理能力完全看你配置的熟悉能力。

    软件四层交换我们可以使用Linux上常用的LVS来解决,LVS就是Linux Virtual Server,他提供了基于心跳线heartbeat的实时灾难应对解决方案,提高系统的鲁棒性,同时可供了灵活的虚拟VIP配置和管理功能,可以同时满足多种应用需求,这对于分布式的系统来说必不可少。

    一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被采用,这样的架构低成本、高性能还有很强的扩张性,随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。




    一:高并发高负载类网站关注点之数据库

    没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是Web2.0的应用,数据库的响应是首先要解决的。
    一般来说mysql是最常用的,可能最初是一个mysql主机,当数据增加到100万以上,那么,MySQL的效能急剧下降。常用的优化措施是M-S(主-从)方式进行同步复制,将查询和操作和分别在不同的服务器上进行操作。我推荐的是M-M-Slaves方式,2个主Mysql,多个Slaves,需要注意的是,虽然有2个Master,但是同时只有1个是Active,我们可以在一定时候切换。之所以用2个M,是保证M不会又成为系统的SPOF。
    Slaves可以进一步负载均衡,可以结合LVS,从而将select操作适当的平衡到不同的slaves上。
    以上架构可以抗衡到一定量的负载,但是随着用户进一步增加,你的用户表数据超过1千万,这时那个M变成了SPOF。你不能任意扩充Slaves,否则复制同步的开销将直线上升,怎么办?我的方法是表分区,从业务层面上进行分区。最简单的,以用户数据为例。根据一定的切分方式,比如id,切分到不同的数据库集群去。

    全局数据库用于meta数据的查询。缺点是每次查询,会增加一次,比如你要查一个用户nightsailer,你首先要到全局数据库群找到nightsailer对应的cluster id,然后再到指定的cluster找到nightsailer的实际数据。
    每个cluster可以用m-m方式,或者m-m-slaves方式。这是一个可以扩展的结构,随着负载的增加,你可以简单的增加新的mysql cluster进去。

    需要注意的是:
    1、禁用全部auto_increment的字段
    2、id需要采用通用的算法集中分配
    3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。
    4、不要使用持久性链接(不要用pconnect),相反,使用sqlrelay这种第三方的数据库链接池,或者干脆自己做,因为php4中mysql的链接池经常出问题。

    二:高并发高负载网站的系统架构之HTML静态化

    其实大家都知道,效率最高、消耗最小的就是纯静态化 http://www.ablanxue.com/shtml/201207/776.shtml的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是 最有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点 的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限 管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。
      
      除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化,有更新的时候再重新静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。
      
       同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用html静态化来实现,比如论坛 中论坛的公用设置信息,这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以考虑将这 部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求高并发。
      

    网站HTML静态化解决方案
    当一个Servlet资源请求到达WEB服务器之后我们会填充指定的JSP页面来响应请求:

    HTTP请求---Web服务器---Servlet--业务逻辑处理--访问数据--填充JSP--响应请求

    HTML静态化之后:

    HTTP请求---Web服务器---Servlet--HTML--响应请求

    静态访求如下

    Servlet:

    public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
    if(request.getParameter("chapterId") != null){
    String chapterFileName = "bookChapterRead_"+request.getParameter("chapterId")+".html";
    String chapterFilePath = getServletContext().getRealPath("/") + chapterFileName;
    File chapterFile = new File(chapterFilePath);
    if(chapterFile.exists()){response.sendRedirect(chapterFileName);return;}//如果有这个文件就告诉浏览器转向
    INovelChapterBiz novelChapterBiz = new NovelChapterBizImpl();
    NovelChapter novelChapter = novelChapterBiz.searchNovelChapterById(Integer.parseInt(request.getParameter("chapterId")));//章节信息
    int lastPageId = novelChapterBiz.searchLastCHapterId(novelChapter.getNovelId().getId(), novelChapter.getId());
    int nextPageId = novelChapterBiz.searchNextChapterId(novelChapter.getNovelId().getId(), novelChapter.getId());
    request.setAttribute("novelChapter", novelChapter);
    request.setAttribute("lastPageId", lastPageId);
    request.setAttribute("nextPageId", nextPageId);
    new CreateStaticHTMLPage().createStaticHTMLPage(request, response, getServletContext(),
    chapterFileName, chapterFilePath, "/bookRead.jsp");
    }
    }
    生成HTML静态页面的类:

    package com.jb.y2t034.thefifth.web.servlet;
    import java.io.ByteArrayOutputStream;
    import java.io.FileOutputStream;
    import java.io.IOException;
    import java.io.OutputStreamWriter;
    import java.io.PrintWriter;
    import javax.servlet.RequestDispatcher;
    import javax.servlet.ServletContext;
    import javax.servlet.ServletException;
    import javax.servlet.ServletOutputStream;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    import javax.servlet.http.HttpServletResponseWrapper;
    /**
    * 创建HTML静态页面
    * 功能:创建HTML静态页面
    * 时间:2009年1011日
    * 地点:home
    * @author mavk
    *
    */
    public class CreateStaticHTMLPage {
    /**
    * 生成静态HTML页面的方法
    * @param request 请求对象
    * @param response 响应对象
    * @param servletContext Servlet上下文
    * @param fileName 文件名称
    * @param fileFullPath 文件完整路径
    * @param jspPath 需要生成静态文件的JSP路径(相对即可)
    * @throws IOException
    * @throws ServletException
    */
    public void createStaticHTMLPage(HttpServletRequest request, HttpServletResponse response,ServletContext servletContext,String fileName,String fileFullPath,String jspPath) throws ServletException, IOException{
    response.setContentType("text/html;charset=gb2312");//设置HTML结果流编码(即HTML文件编码)
    RequestDispatcher rd = servletContext.getRequestDispatcher(jspPath);//得到JSP资源
    final ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();//用于从ServletOutputStream中接收资源
    final ServletOutputStream servletOuputStream = new ServletOutputStream(){//用于从HttpServletResponse中接收资源
    public void write(byte[] b, int off,int len){
    byteArrayOutputStream.write(b, off, len);
    }
    public void write(int b){
    byteArrayOutputStream.write(b);
    }
    };
    final PrintWriter printWriter = new PrintWriter(new OutputStreamWriter(byteArrayOutputStream));//把转换字节流转换成字符流
    HttpServletResponse httpServletResponse = new HttpServletResponseWrapper(response){//用于从response获取结果流资源(重写了两个方法)
    public ServletOutputStream getOutputStream(){
    return servletOuputStream;
    }
    public PrintWriter getWriter(){
    return printWriter;
    }
    };
    rd.include(request, httpServletResponse);//发送结果流
    printWriter.flush();//刷新缓冲区,把缓冲区的数据输出
    FileOutputStream fileOutputStream = new FileOutputStream(fileFullPath);
    byteArrayOutputStream.writeTo(fileOutputStream);//把byteArrayOuputStream中的资源全部写入到fileOuputStream中
    fileOutputStream.close();//关闭输出流,并释放相关资源
    response.sendRedirect(fileName);//发送指定文件流到客户端
    }
    }

    三:高并发高负载类网站关注点之缓存、负载均衡、存储

    缓存是另一个大问题,我一般用memcached来做缓存集群,一般来说部署10台左右就差不多(10g内存池)。需要注意一点,千万不能用使用
    swap,最好关闭linux的swap。


    负载均衡/加速

    可能上面说缓存的时候,有人第一想的是页面静态化,所谓的静态html,我认为这是常识,不属于要点了。页面的静态化随之带来的是静态服务的
    负载均衡和加速。我认为Lighttped+Squid是最好的方式了。
    LVS <------->lighttped====>squid(s) ====lighttpd

    上面是我经常用的。注意,我没有用apache,除非特定的需求,否则我不部署apache,因为我一般用php-fastcgi配合lighttpd,
    性能比apache+mod_php要强很多。

    squid的使用可以解决文件的同步等等问题,但是需要注意,你要很好的监控缓存的命中率,尽可能的提高的90%以上。
    squid和lighttped也有很多的话题要讨论,这里不赘述。


    存储
    存储也是一个大问题,一种是小文件的存储,比如图片这类。另一种是大文件的存储,比如搜索引擎的索引,一般单文件都超过2g以上。
    小文件的存储最简单的方法是结合lighttpd来进行分布。或者干脆使用Redhat的GFS,优点是应用透明,缺点是费用较高。我是指
    你购买盘阵的问题。我的项目中,存储量是2-10Tb,我采用了分布式存储。这里要解决文件的复制和冗余。
    这样每个文件有不同的冗余,这方面可以参考google的gfs的论文。
    大文件的存储,可以参考nutch的方案,现在已经独立为Hadoop子项目。(你可以google it)

    其他:
    此外,passport等也是考虑的,不过都属于比较简单的了。
    四:高并发高负载网站的系统架构之图片服务器分离
    大家知道,对于Web 服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他 们都有独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃,在应用 服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持,尽可能少的LoadModule, 保证更高的系统消耗和执行效率。


    利用Apache实现图片服务器的分离
    缘由:
    起步阶段的应用,都可能部署在一台服务器上(费用上的原因)
    第一个优先分离的,肯定是数据库和应用服务器。
    第二个分离的,会是什么呢?各有各的考虑,我所在的项目组重点考虑的节约带宽,服务器性能再好,带宽再高,并发来了,也容易撑不住。因此,我这篇文章的重点在这里。这里重点是介绍实践,不一定符合所有情况,供看者参考吧,
    环境介绍:
    WEB应用服务器:4CPU双核2G, 内存4G
    部署:Win2003/Apache Http Server 2.1/Tomcat6
    数据库服务器:4CPU双核2G, 内存4G
    部署:Win2003/MSSQL2000
    步骤:
    步骤一:增加2台配置为:2CPU双核2G,内存2G普通服务器,做资源服务器
    部署:Tomcat6,跑了一个图片上传的简单应用,(记得指定web.xml的<distributable/>),并指定域名为res1.***.com,res2.***.com,采用ajp协议
    步骤二:修改Apache httpd.conf配置
    原来应用的文件上传功能网址为:
    1、/fileupload.html
    2、/otherupload.html
    在httpd.conf中增加如下配置

    <VirtualHost *:80>
    ServerAdmin webmaster@***.com
    ProxyPass /fileupload.html balancer://rescluster/fileupload lbmethod=byrequests stickysession=JSESSIONID nofailover=Off timeout=5 maxattempts=3
    ProxyPass /otherupload.html balancer://rescluster/otherupload.html lbmethod=byrequests stickysession=JSESSIONID nofailover=Off timeout=5 maxattempts=3
    #<!--负载均衡-->
    <Proxy balancer://rescluster/>
    BalancerMember ajp://res1.***.com:8009 smax=5 max=500 ttl=120 retry=300 loadfactor=100 route=tomcat1
    BalancerMember ajp://res2.***.com:8009 smax=5 max=500 ttl=120 retry=300 loadfactor=100 route=tomcat2
    </Proxy>

    < /VirtualHost>
    步骤三,修改业务逻辑:
    所有上传文件在数据库中均采用全url的方式保存,例如产品图片路径存成:http://res1.***.com/upload/20090101/product120302005.jpg

    现在,你可以高枕无忧了,带宽不够时,增加个几十台图片服务器,只需要稍微修改一下apache的配置文件,即可。

    五:高并发高负载网站的系统架构之数据库集群和库表散列

    大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。
      
      在数据库集群方面,很多数据库都有自己的解决方案,oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。
      
       上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并 且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者 功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的 架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的配置便能让系 统随时增加一台低成本的数据库进来补充系统性能。


    集群软件的分类:
    一般来讲,集群软件根据侧重的方向和试图解决的问题,分为三大类:高性能集群(High performance cluster,HPC)、负载均衡集群(Load balance cluster, LBC),高可用性集群(High availability cluster,HAC)。
    高性能集群(High performance cluster,HPC),它是利用一个集群中的多台机器共同完成同一件任务,使得完成任务的速度和可靠性都远远高于单机运行的效果。弥补了单机性能上的不足。该集群在天气预报、环境监控等数据量大,计算复杂的环境中应用比较多;
    负载均衡集群(Load balance cluster, LBC),它是利用一个集群中的多台单机,完成许多并行的小的工作。一般情况下,如果一个应用使用的人多了,那么用户请求的响应时间就会增大,机器的性能也会受到影响,如果使用负载均衡集群,那么集群中任意一台机器都能响应用户的请求,这样集群就会在用户发出服务请求之后,选择当时负载最小,能够提供最好的服务的这台机器来接受请求并相应,这样就可用用集群来增加系统的可用性和稳定性。这类集群在网站中使用较多;
    高可用性集群(High availability cluster,HAC),它是利用集群中系统 的冗余,当系统中某台机器发生损坏的时候,其他后备的机器可以迅速的接替它来启动服务,等待故障机的维修和返回。最大限度的保证集群中服务的可用性。这类系统一般在银行,电信服务这类对系统可靠性有高的要求的领域有着广泛的应用。
    2 数据库集群的现状
    数据库集群是将计算机集群技术引入到数据库中来实现的,尽管各厂商宣称自己的架构如何的完美,但是始终不能改变Oracle当先,大家追逐的事实,在集群的解决方案上Oracle RAC还是领先于包括微软在内的其它数据库厂商,它能满足客户高可用性、高性能、数据库负载均衡和方便扩展的需求。
    Oracle’s Real Application Cluster (RAC)
    Microsoft SQL Cluster Server (MSCS)
    IBM’s DB2 UDB High Availability Cluster(UDB)
    Sybase ASE High Availability Cluster (ASE)
    MySQL High Availability Cluster (MySQL CS)
    基于IO的第三方HA(高可用性)集群
    当前主要的数据库集群技术有以上六大类,有数据库厂商自己开发的;也有第三方的集群公司开发的;还有数据库厂商与第三方集群公司合作开发的,各类集群实现的功能及架构也不尽相同。
    RAC(Real Application Cluster,真正应用集群)是Oracle9i数据库中采用的一项新技术,也是Oracle数据库支持网格计算环境的核心技术。它的出现解决了传统数据库应用中面临的一个重要问题:高性能、高可伸缩性与低价格之间的矛盾。在很长一段时间里,甲骨文都以其实时应用集群技术(Real Application Cluster,RAC)统治着集群数据库市场

    六:高并发高负载网站的系统架构之缓存

    缓存一词搞技术的都接触过,很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
      架构方面的缓存,对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力。
       网站程序开发方面的缓存,Linux上提供的Memory Cache是常用的缓存接口,可以在web开发中使用,比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享,一些大 型社区使用了这样的架构。另外,在使用web语言开发的时候,各种语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块,Java就更多 了,.net不是很熟悉,相信也肯定有。

    Java开源缓存框架
    JBossCache/TreeCache JBossCache是一个复制的事务处理缓存,它允许你缓存企业级应用数据来更好的改善性能。缓存数据被自动复制,让你轻松进行Jboss服务器之间的集群工作。JBossCache能够通过Jboss应用服务或其他J2EE容器来运行一个Mbean服务,当然,它也能独立运行。 JBossCache包括两个模块:TreeCache和TreeCacheAOP。 TreeCache --是一个树形结构复制的事务处理缓存。 TreeCacheAOP --是一个“面向对象”缓存,它使用AOP来动态管理POJO
    OSCache OSCache标记库由OpenSymphony设计,它是一种开创性的JSP定制标记应用,提供了在现有JSP页面之内实现快速内存缓冲的功能。OSCache是个一个广泛采用的高性能的J2EE缓存框架,OSCache能用于任何Java应用程序的普通的缓存解决方案。OSCache有以下特点:缓存任何对象,你可以不受限制的缓存部分jsp页面或HTTP请求,任何java对象都可以缓存。 拥有全面的API--OSCache API给你全面的程序来控制所有的OSCache特性。 永久缓存--缓存能随意的写入硬盘,因此允许昂贵的创建(expensive-to-create)数据来保持缓存,甚至能让应用重启。 支持集群--集群缓存数据能被单个的进行参数配置,不需要修改代码。 缓存记录的过期--你可以有最大限度的控制缓存对象的过期,包括可插入式的刷新策略(如果默认性能不需要时)。
    JCACHE JCACHE是一种即将公布的标准规范(JSR 107),说明了一种对Java对象临时在内存中进行缓存的方法,包括对象的创建、共享访问、假脱机(spooling)、失效、各JVM的一致性等。它可被用于缓存JSP内最经常读取的数据,如产品目录和价格列表。利用JCACHE,多数查询的反应时间会因为有缓存的数据而加快(内部测试表明反应时间大约快15倍)。
    Ehcache Ehcache出自hibernate,在Hibernate中使用它作为数据缓存的解决方案。
    Java Caching System JCS是Jakarta的项目Turbine的子项目。它是一个复合式的缓冲工具。可以将对象缓冲到内存、硬盘。具有缓冲对象时间过期设定。还可以通过JCS构建具有缓冲的分布式构架,以实现高性能的应用。 对于一些需要频繁访问而每访问一次都非常消耗资源的对象,可以临时存放在缓冲区中,这样可以提高服务的性能。而JCS正是一个很好的缓冲工具。缓冲工具对于读操作远远多于写操作的应用性能提高非常显著。
    SwarmCache SwarmCache是一个简单而功能强大的分布式缓存机制。它使用IP组播来有效地在缓存的实例之间进行通信。它是快速提高集群式Web应用程序的性能的理想选择。
    ShiftOne ShiftOne Object Cache这个Java库提供了基本的对象缓存能力。实现的策略有先进先出(FIFO),最近使用(LRU),最不常使用(LFU)。所有的策略可以最大化元素的大小,最大化其生存时间。
    WhirlyCache Whirlycache是一个快速的、可配置的、存在于内存中的对象的缓存。它能够通过缓存对象来加快网站或应用程序的速度,否则就必须通过查询数据库或其他代价较高的处理程序来建立。
    Jofti Jofti可对在缓存层中(支持EHCache,JBossCache和OSCache)的对象或在支持Map接口的存储结构中的对象进行索引与搜索。这个框架还为对象在索引中的增删改提供透明的功能同样也为搜索提供易于使用的查询功能。
    cache4j cache4j是一个有简单API与实现快速的Java对象缓存。它的特性包括:在内存中进行缓存,设计用于多线程环境,两种实现:同步与阻塞,多种缓存清除策略:LFU, LRU, FIFO,可使用强引用(strong reference)与软引用(soft reference)存储对象。
    Open Terracotta 一个JVM级的开源群集框架,提供:HTTP Session复制,分布式缓存,POJO群集,跨越群集的JVM来实现分布式应用程序协调(采用代码注入的方式,所以你不需要修改任何)。
    sccache SHOP.COM使用的对象缓存系统。sccache是一个in-process cache和二级、共享缓存。它将缓存对象存储到磁盘上。支持关联Key,任意大小的Key和任意大小的数据。能够自动进行垃圾收集。
    Shoal Shoal是一个基于Java可扩展的动态集群框架,能够为构建容错、可靠和可用的Java应用程序提供了基础架构支持。这个框架还可以集成到不希望绑定到特定通信协议,但需要集群和分布式系统支持的任何Java产品中。Shoal是GlassFish和JonAS应用服务器的集群引擎。
    Simple-spring-Memcached Simple-Spring-Memcached,它封装了对MemCached的调用,使MemCached的客户端开发变得超乎寻常的简单。

    展开全文
  • Web系统大规模并发处理

    千次阅读 2017-01-23 22:11:57
    面对5w每秒的高并发秒杀功能,如果Web系统不做针对性的优化,会轻而易举地陷入到异常状态。我们现在一起来讨论下,优化的思路和方法哈。  1. 请求接口的合理设计 一个秒杀或者抢购页面,通常分为2个部分,...

    一、大规模并发带来的挑战 

    面对5w每秒的高并发秒杀功能,如果Web系统不做针对性的优化,会轻而易举地陷入到异常状态。我们现在一起来讨论下,优化的思路和方法哈。 

    1. 请求接口的合理设计

    一个秒杀或者抢购页面,通常分为2个部分,一个是静态的HTML等内容,另一个就是参与秒杀的Web后台请求接口。

    通常静态HTML等内容,是通过CDN的部署,一般压力不大,核心瓶颈实际上在后台请求接口上。这个后端接口,必须能够支持高并发请求,同时,非常重要的一点,必须尽可能“快”,在最短的时间里返回用户的请求结果。为了实现尽可能快这一点,接口的后端存储使用内存级别的操作会更好一点。仍然直接面向MySQL之类的存储是不合适的,如果有这种复杂业务的需求,都建议采用异步写入。

     

    当然,也有一些秒杀和抢购采用“滞后反馈”,就是说秒杀当下不知道结果,一段时间后才可以从页面中看到用户是否秒杀成功。但是,这种属于“偷懒”行为,同时给用户的体验也不好,容易被用户认为是“暗箱操作”。

    2. 高并发的挑战:一定要“快”

    我们通常衡量一个Web系统的吞吐率的指标是QPS(Query Per Second,每秒处理请求数),解决每秒数万次的高并发场景,这个指标非常关键。举个例子,我们假设处理一个业务请求平均响应时间为100ms,同时,系统内有20台Apache的Web服务器,配置MaxClients为500个(表示Apache的最大连接数目)。

    那么,我们的Web系统的理论峰值QPS为(理想化的计算方式):

    20*500/0.1 = 100000 (10万QPS)

    咦?我们的系统似乎很强大,1秒钟可以处理完10万的请求,5w/s的秒杀似乎是“纸老虎”哈。实际情况,当然没有这么理想。在高并发的实际场景下,机器都处于高负载的状态,在这个时候平均响应时间会被大大增加。

    就Web服务器而言,Apache打开了越多的连接进程,CPU需要处理的上下文切换也越多,额外增加了CPU的消耗,然后就直接导致平均响应时间增加。因此上述的MaxClient数目,要根据CPU、内存等硬件因素综合考虑,绝对不是越多越好。可以通过Apache自带的abench来测试一下,取一个合适的值。然后,我们选择内存操作级别的存储的Redis,在高并发的状态下,存储的响应时间至关重要。网络带宽虽然也是一个因素,不过,这种请求数据包一般比较小,一般很少成为请求的瓶颈。负载均衡成为系统瓶颈的情况比较少,在这里不做讨论哈。

    那么问题来了,假设我们的系统,在5w/s的高并发状态下,平均响应时间从100ms变为250ms(实际情况,甚至更多):

    20*500/0.25 = 40000 (4万QPS)

    于是,我们的系统剩下了4w的QPS,面对5w每秒的请求,中间相差了1w。

    然后,这才是真正的恶梦开始。举个例子,高速路口,1秒钟来5部车,每秒通过5部车,高速路口运作正常。突然,这个路口1秒钟只能通过4部车,车流量仍然依旧,结果必定出现大塞车。(5条车道忽然变成4条车道的感觉)

    同理,某一个秒内,20*500个可用连接进程都在满负荷工作中,却仍然有1万个新来请求,没有连接进程可用,系统陷入到异常状态也是预期之内。

     

    其实在正常的非高并发的业务场景中,也有类似的情况出现,某个业务请求接口出现问题,响应时间极慢,将整个Web请求响应时间拉得很长,逐渐将Web服务器的可用连接数占满,其他正常的业务请求,无连接进程可用。

    更可怕的问题是,是用户的行为特点,系统越是不可用,用户的点击越频繁,恶性循环最终导致“雪崩”(其中一台Web机器挂了,导致流量分散到其他正常工作的机器上,再导致正常的机器也挂,然后恶性循环),将整个Web系统拖垮。

    3. 重启与过载保护

    如果系统发生“雪崩”,贸然重启服务,是无法解决问题的。最常见的现象是,启动起来后,立刻挂掉。这个时候,最好在入口层将流量拒绝,然后再将重启。如果是redis/memcache这种服务也挂了,重启的时候需要注意“预热”,并且很可能需要比较长的时间。

    秒杀和抢购的场景,流量往往是超乎我们系统的准备和想象的。这个时候,过载保护是必要的。如果检测到系统满负载状态,拒绝请求也是一种保护措施。在前端设置过滤是最简单的方式,但是,这种做法是被用户“千夫所指”的行为。更合适一点的是,将过载保护设置在CGI入口层,快速将客户的直接请求返回。

    二、作弊的手段:进攻与防守

    秒杀和抢购收到了“海量”的请求,实际上里面的水分是很大的。不少用户,为了“抢“到商品,会使用“刷票工具”等类型的辅助工具,帮助他们发送尽可能多的请求到服务器。还有一部分高级用户,制作强大的自动请求脚本。这种做法的理由也很简单,就是在参与秒杀和抢购的请求中,自己的请求数目占比越多,成功的概率越高。

    这些都是属于“作弊的手段”,不过,有“进攻”就有“防守”,这是一场没有硝烟的战斗哈。

    1. 同一个账号,一次性发出多个请求

    部分用户通过浏览器的插件或者其他工具,在秒杀开始的时间里,以自己的账号,一次发送上百甚至更多的请求。实际上,这样的用户破坏了秒杀和抢购的公平性。

    这种请求在某些没有做数据安全处理的系统里,也可能造成另外一种破坏,导致某些判断条件被绕过。例如一个简单的领取逻辑,先判断用户是否有参与记录,如果没有则领取成功,最后写入到参与记录中。这是个非常简单的逻辑,但是,在高并发的场景下,存在深深的漏洞。多个并发请求通过负载均衡服务器,分配到内网的多台Web服务器,它们首先向存储发送查询请求,然后,在某个请求成功写入参与记录的时间差内,其他的请求获查询到的结果都是“没有参与记录”。这里,就存在逻辑判断被绕过的风险。

     


    应对方案:

    在程序入口处,一个账号只允许接受1个请求,其他请求过滤。不仅解决了同一个账号,发送N个请求的问题,还保证了后续的逻辑流程的安全。实现方案,可以通过Redis这种内存缓存服务,写入一个标志位(只允许1个请求写成功,结合watch的乐观锁的特性),成功写入的则可以继续参加。

     

    或者,自己实现一个服务,将同一个账号的请求放入一个队列中,处理完一个,再处理下一个。

    2. 多个账号,一次性发送多个请求

    很多公司的账号注册功能,在发展早期几乎是没有限制的,很容易就可以注册很多个账号。因此,也导致了出现了一些特殊的工作室,通过编写自动注册脚本,积累了一大批“僵尸账号”,数量庞大,几万甚至几十万的账号不等,专门做各种刷的行为(这就是微博中的“僵尸粉“的来源)。举个例子,例如微博中有转发抽奖的活动,如果我们使用几万个“僵尸号”去混进去转发,这样就可以大大提升我们中奖的概率。

    这种账号,使用在秒杀和抢购里,也是同一个道理。例如,iPhone官网的抢购,火车票黄牛党。

     

    应对方案:

    这种场景,可以通过检测指定机器IP请求频率就可以解决,如果发现某个IP请求频率很高,可以给它弹出一个验证码或者直接禁止它的请求:

    1. 弹出验证码,最核心的追求,就是分辨出真实用户。因此,大家可能经常发现,网站弹出的验证码,有些是“鬼神乱舞”的样子,有时让我们根本无法看清。他们这样做的原因,其实也是为了让验证码的图片不被轻易识别,因为强大的“自动脚本”可以通过图片识别里面的字符,然后让脚本自动填写验证码。实际上,有一些非常创新的验证码,效果会比较好,例如给你一个简单问题让你回答,或者让你完成某些简单操作(例如百度贴吧的验证码)。
    2. 直接禁止IP,实际上是有些粗暴的,因为有些真实用户的网络场景恰好是同一出口IP的,可能会有“误伤“。但是这一个做法简单高效,根据实际场景使用可以获得很好的效果。

    3. 多个账号,不同IP发送不同请求

    所谓道高一尺,魔高一丈。有进攻,就会有防守,永不休止。这些“工作室”,发现你对单机IP请求频率有控制之后,他们也针对这种场景,想出了他们的“新进攻方案”,就是不断改变IP。

     

    有同学会好奇,这些随机IP服务怎么来的。有一些是某些机构自己占据一批独立IP,然后做成一个随机代理IP的服务,有偿提供给这些“工作室”使用。还有一些更为黑暗一点的,就是通过木马黑掉普通用户的电脑,这个木马也不破坏用户电脑的正常运作,只做一件事情,就是转发IP包,普通用户的电脑被变成了IP代理出口。通过这种做法,黑客就拿到了大量的独立IP,然后搭建为随机IP服务,就是为了挣钱。

    应对方案:

    说实话,这种场景下的请求,和真实用户的行为,已经基本相同了,想做分辨很困难。再做进一步的限制很容易“误伤“真实用户,这个时候,通常只能通过设置业务门槛高来限制这种请求了,或者通过账号行为的”数据挖掘“来提前清理掉它们。

    僵尸账号也还是有一些共同特征的,例如账号很可能属于同一个号码段甚至是连号的,活跃度不高,等级低,资料不全等等。根据这些特点,适当设置参与门槛,例如限制参与秒杀的账号等级。通过这些业务手段,也是可以过滤掉一些僵尸号。

    4. 火车票的抢购

    看到这里,同学们是否明白你为什么抢不到火车票?如果你只是老老实实地去抢票,真的很难。通过多账号的方式,火车票的黄牛将很多车票的名额占据,部分强大的黄牛,在处理验证码方面,更是“技高一筹“。

    高级的黄牛刷票时,在识别验证码的时候使用真实的人,中间搭建一个展示验证码图片的中转软件服务,真人浏览图片并填写下真实验证码,返回给中转软件。对于这种方式,验证码的保护限制作用被废除了,目前也没有很好的解决方案。

     

    因为火车票是根据身份证实名制的,这里还有一个火车票的转让操作方式。大致的操作方式,是先用买家的身份证开启一个抢票工具,持续发送请求,黄牛账号选择退票,然后黄牛买家成功通过自己的身份证购票成功。当一列车厢没有票了的时候,是没有很多人盯着看的,况且黄牛们的抢票工具也很强大,即使让我们看见有退票,我们也不一定能抢得过他们哈。 

     

    最终,黄牛顺利将火车票转移到买家的身份证下。

    解决方案:

    并没有很好的解决方案,唯一可以动心思的也许是对账号数据进行“数据挖掘”,这些黄牛账号也是有一些共同特征的,例如经常抢票和退票,节假日异常活跃等等。将它们分析出来,再做进一步处理和甄别。

    三、高并发下的数据安全

    我们知道在多线程写入同一个文件的时候,会存现“线程安全”的问题(多个线程同时运行同一段代码,如果每次运行结果和单线程运行的结果是一样的,结果和预期相同,就是线程安全的)。如果是MySQL数据库,可以使用它自带的锁机制很好的解决问题,但是,在大规模并发的场景中,是不推荐使用MySQL的。秒杀和抢购的场景中,还有另外一个问题,就是“超发”,如果在这方面控制不慎,会产生发送过多的情况。我们也曾经听说过,某些电商搞抢购活动,买家成功拍下后,商家却不承认订单有效,拒绝发货。这里的问题,也许并不一定是商家奸诈,而是系统技术层面存在超发风险导致的。

    1. 超发的原因

    假设某个抢购场景中,我们一共只有100个商品,在最后一刻,我们已经消耗了99个商品,仅剩最后一个。这个时候,系统发来多个并发请求,这批请求读取到的商品余量都是99个,然后都通过了这一个余量判断,最终导致超发。(同文章前面说的场景)

     

    在上面的这个图中,就导致了并发用户B也“抢购成功”,多让一个人获得了商品。这种场景,在高并发的情况下非常容易出现。

    2. 悲观锁思路

    解决线程安全的思路很多,可以从“悲观锁”的方向开始讨论。

    悲观锁,也就是在修改数据的时候,采用锁定状态,排斥外部请求的修改。遇到加锁的状态,就必须等待。

     

    虽然上述的方案的确解决了线程安全的问题,但是,别忘记,我们的场景是“高并发”。也就是说,会很多这样的修改请求,每个请求都需要等待“锁”,某些线程可能永远都没有机会抢到这个“锁”,这种请求就会死在那里。同时,这种请求会很多,瞬间增大系统的平均响应时间,结果是可用连接数被耗尽,系统陷入异常。

    3. FIFO队列思路

    那好,那么我们稍微修改一下上面的场景,我们直接将请求放入队列中的,采用FIFO(First Input First Output,先进先出),这样的话,我们就不会导致某些请求永远获取不到锁。看到这里,是不是有点强行将多线程变成单线程的感觉哈。

     

    然后,我们现在解决了锁的问题,全部请求采用“先进先出”的队列方式来处理。那么新的问题来了,高并发的场景下,因为请求很多,很可能一瞬间将队列内存“撑爆”,然后系统又陷入到了异常状态。或者设计一个极大的内存队列,也是一种方案,但是,系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说,队列内的请求会越积累越多,最终Web系统平均响应时候还是会大幅下降,系统还是陷入异常。

    4. 乐观锁思路

    这个时候,我们就可以讨论一下“乐观锁”的思路了。乐观锁,是相对于“悲观锁”采用更为宽松的加锁机制,大都是采用带版本号(Version)更新。实现就是,这个数据所有请求都有资格去修改,但会获得一个该数据的版本号,只有版本号符合的才能更新成功,其他的返回抢购失败。这样的话,我们就不需要考虑队列的问题,不过,它会增大CPU的计算开销。但是,综合来说,这是一个比较好的解决方案。

     

    有很多软件和服务都“乐观锁”功能的支持,例如Redis中的watch就是其中之一。通过这个实现,我们保证了数据的安全。

    四、小结

    互联网正在高速发展,使用互联网服务的用户越多,高并发的场景也变得越来越多。电商秒杀和抢购,是两个比较典型的互联网高并发场景。虽然我们解决问题的具体技术方案可能千差万别,但是遇到的挑战却是相似的,因此解决问题的思路也异曲同工。

    展开全文
  • 操作系统中并行和并发的概念

    千次阅读 2017-08-13 22:30:45
    在单处理机系统中,下述并行和并发现象哪些可能发生,哪些不会发生? (1) 进程与进程之间的并行; (2) 进程与进程之间的并发; (3) 处理机与设备之间的并行; (4) 处理机与通道之间的并行; (5) 通道与通道之间...
  • 并发技术

    万次阅读 多人点赞 2019-10-21 16:45:04
    并发技术 第一章 预备知识一 理解大数据二 网工基础知识OSI七层参考模型应用层表示层会话层传输层网络层链路层物理层功能分层总结第二章 LVS技术一 LVS介绍二 LVS调度算法LVS命令监控多个端口号管理服务集群的...
  • 实际应用,可能会发生消费者收到Queue的消息,但没有处理完成就宕(或出现其他意外)的情况,这种情况下就可能会导致消息丢失。 为了避免这种情况发生,我们可以要求消费者消费完消息发送一个回执给...
  • cassandra 并发技术介绍

    万次阅读 2016-07-02 09:48:06
    本文主要介绍cassandra线程技术,cassandra的实现是基于java的,所以线程技术使用的也是jdk包提供的线程类。cassandra是分布式数据库,整个并发架构是基于阶段事件驱动架构(staged envent-driven architecture)它...
  • 并发处理/服务器宕机处理

    万次阅读 2017-04-05 15:54:21
    一、 web加速相关技术 1. 镜像站点 2. DNS负载均衡 3. CDN内容分发 二、 内网加速技术 1. 负载均衡(软件负载均衡、硬件负载均衡) 2. Web缓存服务器 3. Web/应用服务器分布式文件系统 4. 分布式...
  • 单机并发是集群并发的基础。本文主要将单机并发问题,和解决单机并发问题解决模型。
  • 并发处理方案

    千次阅读 2018-02-17 19:07:18
    并发和大流量:并发操作系统中,是指一个时间段有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是同一个处理机上运行,但任一个时刻点上只有一个程序在处理机上运行。但是我们所说的并发是:...
  • 来源:InfoQ 作者:方乐明 背景介绍 ...面对挑战,微信红包分析了业界“秒杀”系统解决方案的基础上,采用了SET化、请求排队串行化、双维度分库表等设计,形成了独特的高并发、资金安全系统解决方
  • 主要讲解高可用的互联网交易系统架构,包括双十一、支付宝&微博红包技术架构,以及微信红包的技术架构,希望能给各位提供价值。   概述 话说每逢双十一节或春节等节假日,对大家来讲是最欢乐的日子,可以...
  • 何谓高并发?不同的应用系统具有不同的...这个数值相比较于电信计费系统并发数而言,数值上可能比较小,但如果同时参考税收征管业务的复杂性,就会体会到服务器要承载的计算负荷是非常巨大的了。除并发数指标外,
  • 如何处理并发

    万次阅读 多人点赞 2018-05-18 22:38:48
    比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放一个目录下,这样的网站对系统架构、性能的要求都很简单,随着互联网业务的不断丰富,网站相关的技术经过这些年...
  • 为了解决大型网站面临的高并发访问、海量数据处理、高可靠运行等一系列问题与挑战,大型互联网公司实践提出了许多解决方案,以实现网站高性能、高可用、易伸缩、可扩展、安全等各种技术架构目标。这些解决方案又...
  • 因此记者第一时间联系到一位对12306改造非常关注的技术架构师,他从技术的角度,用科学论证的方式,指出原因所在,并根据他的经验进一步说明12306是如何实现高流量高并发的关键技术,与大家共享。以下为正文: ...
  • 文章说明:本文是学习一个网络爬虫课程时所做笔记,文章如有不对的地方,欢迎指出,积极讨论。 墨菲定律: 1)任何事情没有看起来那么简单 2)所有的事情都会比你预计的时间长 3)可能出错的事情会出错 4)...
  • 来源:知乎 ...实际系统中有很多操作,是不管做多少次,都应该产生一样的效果或返回一样的结果。 例如: 1. 前端重复提交选中的数据,应该后台只产生对应这个数据的一个反应结果。 2. 我们发
  • 电商的秒杀和抢购,对我们来说,都不是一个陌生的东西。然而,从技术的角度来说,这对于Web系统是一个巨大的考验。当一个Web系统一秒钟内收到数以万计甚至...过去的工作,我曾经面对过5w每秒的高并发秒杀功能,
  • bilibili 高并发实时弹幕系统实现

    万次阅读 2017-03-30 16:57:16
    并发实时弹幕是一种互动的体验。对于互动来说,考虑最多的地方就是:高稳定性、高可用性以及低延迟这三个方面。 高稳定性,为了保证互动的实时性,所以要求连接状态稳定; 高可用性,相当于提供一种备用...
  • Java并发编程与技术内幕:线程池深入理解

    万次阅读 多人点赞 2016-06-08 08:38:57
     摘要: 本文主要讲了Java当中的线程池的使用方法、注意事项及其实现源码实现原理,并辅以实例加以说明,对加深Java线程池的理解有很大的帮助。  首先,讲讲什么是线程池?照笔者的简单理解,其实就是一组线程实时...
  • Java并发机制及锁的实现原理

    万次阅读 多人点赞 2016-07-18 20:04:21
    Java并发机制及锁实现原理
  • Java Web高并发如何实现

    千次阅读 2019-04-22 13:54:20
    首先第一步,你得让海量请求进来,第二步才是对进来的请求排队处理。...就算vertx台服务器可以处理很高很高的并发,也不可避免要用集群,因为要保障的事高可用,而不只是高并发,跨服务器数据处...
  • 并发(High Concurrency)是互联网分布式系统架构设计必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。 高并发相关常用的一些指标有响应时间(Response Time),吞吐量...
  • Linux 网络编程——并发服务器的三种实现模型

    万次阅读 多人点赞 2015-05-12 17:40:08
    服务器设计技术有很多,按使用的协议来分有 TCP 服务器和 UDP 服务器,按处理方式来分有循环服务器和并发服务器。循环服务器与并发服务器模型网络程序里面,一般来说都是许多客户对应一个服务器(多对一),为了...
  • 《分布式环境下数据库主键方案》 ...只使用数据库时,使用自增主键ID无疑是最适合的。但集群、主从架构上时就会有一些问题,比如:主键的全局唯一。 集群环境下除了自增ID外的其它创建主键...
  • 系统高可用和系统并发

    千次阅读 2018-03-09 15:21:39
    实现一个系统高可用、系统并发的交易处理系统在系统架构设计上,需要有诸多考虑.高可用:指整个系统高可用,也指主机的冗余接管负载均衡概念:负载均衡建立现有网络结构之上,它提供了一种廉价有效透明的方法...
  • 并发的核心技术-幂等的实现方案

    万次阅读 多人点赞 2016-02-09 12:11:09
    并发的核心技术-幂等的实现方案  一、背景  我们实际系统中有很多操作,是不管做多少次,都应该产生一样的效果或返回一样的结果。  例如:  1. 前端重复提交选中的数据,应该后台只产生对应这个数据的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 158,068
精华内容 63,227
关键字:

在单处理机系统中实现并发技术后