关于缓存集群的.docx

Mysql 分区： 5.1以上才有/doc/refman/5.1/zh/partitioning.htmlRANGE 分区：基于属于一个给定连续区间的列值，把多行分配给分区。参见18.2.1节，“RANGE分区”。 CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT 1970-01-01, separated DATE NOT NULL DEFAULT 9999-12-31, job_code INT NOT NULL, store_id INT NOT NULL)PARTITION BY RANGE (store_id) ( PARTITION p0 VALUES LESS THAN (6), PARTITION p1 VALUES LESS THAN (11), PARTITION p2 VALUES LESS THAN (16),PARTITION p3 VALUES LESS THAN (21)PARTITION p4 VALUES LESS THAN MAXVALUE)；LIST 分区：类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择。参见18.2.2节，“LIST分区”。 CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT 1970-01-01, separated DATE NOT NULL DEFAULT 9999-12-31, job_code INT, store_id INT)PARTITION BY LIST(store_id) PARTITION pNorth VALUES IN (3,5,6,9,17), PARTITION pEast VALUES IN (1,2,10,11,19,20), PARTITION pWest VALUES IN (4,12,13,14,18), PARTITION pCentral VALUES IN (7,8,15,16)；ALTER TABLE employees DROP PARTITION pWestHASH分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算。这个函数可以包含MySQL 中有效的、产生非负整数值的任何表达式。参见18.2.3节，“HASH分区”。 要使用HASH分区来分割一个表，要在CREATE TABLE 语句上添加一个“PARTITION BY HASH (expr)”子句，其中“expr”是一个返回一个整数的表达式。它可以仅仅是字段类型为MySQL 整型的一列的名字。此外，你很可能需要在后面再添加一个“PARTITIONS num”子句，其中num 是一个非负的整数，它表示表将要被分割成分区的数量。 CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT 1970-01-01, separated DATE NOT NULL DEFAULT 9999-12-31, job_code INT, store_id INT)PARTITION BY HASH(YEAR(hired)PARTITIONS 4；KEY 分区：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL 服务器提供其自身的哈希函数。必须有一列或多列包含整数值。参见18.2.4节，“KEY分区”。 一、什么是集群？集群（Cluster）是由两台或多台节点机（服务器）构成的一种松散耦合的计算节点集合，为用户提供网络服务或应用程序(包括数据库、Web服务和文件服务等)的单一客户视图，同时提供接近容错机的故障恢复能力。集群系统一般通过两台或多台节点服务器系统通过相应的硬件及软件互连，每个群集节点都是运行其自己进程的独立服务器。这些进程可以彼此通信，对网络客户机来说就像是形成了一个单一系统，协同起来向用户提供应用程序、系统资源和数据。除了作为单一系统提供服务，集群系统还具有恢复服务器级故障的能力。集群系统还可通过在集群中继续增加服务器的方式，从内部增加服务器的处理能力，并通过系统级的冗余提供固有的可靠性和可用性。二、集群的分类：1、高性能计算科学集群：以解决复杂的科学计算问题为目的的IA集群系统。是并行计算的基础，它可以不使用专门的由十至上万个独立处理器组成的并行超级计算机，而是采用通过高速连接来链接的一组1/2/4 CPU的IA服务器，并且在公共消息传递层上进行通信以运行并行应用程序。这样的计算集群，其处理能力与真正超级并行机相等，并且具有优良的性价比。2、负载均衡集群：负载均衡集群为企业需求提供更实用的系统。该系统使各节点的负载流量可以在服务器集群中尽可能平均合理地分摊处理。该负载需要均衡计算的应用程序处理端口负载或网络流量负载。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。对于网络流量也如此。通常，网络服务器应用程序接受了大量入网流量，无法迅速处理，这就需要将流量发送给在其它节点。负载均衡算法还可以根据每个节点不同的可用资源或网络的特殊环境来进行优化。3、高可用性集群：为保证集群整体服务的高可用，考虑计算硬件和软件的容错性。如果高可用性群集中的某个节点发生了故障，那么将由另外的节点代替它。整个系统环境对于用户是一致的。实际应用的集群系统中，这三种基本类型经常会发生混合与交杂。1. 大锅饭调度(Round-Robin Scheduling RR)rr - 纯轮询方式，比较垃圾。把每项请求按顺序在真正服务器中分派。2. 带权重的大锅饭调度(Weighted Round-Robin Scheduling WRR)wrr -带权重轮询方式。把每项请求按顺序在真正服务器中循环分派，但是给能力较大的服务器分派较多的作业。3. 谁不干活就给谁分配(Least-Connection LC)lc - 根据最小连接数分派4. 带权重的谁不干活就给谁分配（Weighted Least-Connections WLC 默认）wlc - 带权重的。机器配置好的权重高。5. 基于地区的最少连接调度(Locality-Based Least-ConnectionScheduling LBLC)lblc - 缓存服务器集群。基于本地的最小连接。把请求传递到负载小的服务器上。6. 带有复制调度的基于地区的最少连接调度(Locality-Based Least-Connection Scheduling with Replication Scheduling LBLCR)lblcr - 带复制调度的缓存服务器集群。某页面缓存在服务器A上，被访问次数极高，而其他缓存服务器负载较低，监视是否访问同一页面，如果是访问同一页面则把请求分到其他服务器。7. 目标散列调度(Destination Hash Scheduling DH)realserver中绑定两个ip。ld判断来者的ISP商，将其转到相应的IP。8. 源散列调度(Source Hash Scheduling SH)源地址散列。基于client地址的来源区分。（用的很少）9. 最短的期望的延迟（Shortest Expected Delay Scheduling SED）基于wlc算法。这个必须举例来说了ABC三台机器分别权重123 ，连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算A:(1+1)/1B:(1+2)/2C:(1+3)/3根据运算结果，把连接交给C 。10.最少队列调度（Never Queue Scheduling NQ）无需队列。如果有台realserver的连接数0就直接分配过去，不需要在进行sed运算。特点（1）高可靠性（HA）。利用集群管理软件，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。（2）高性能计算（HP）。即充分利用集群中的每一台计算机的资源，实现复杂运算的并行处理，通常用于科学计算领域，比如基因分析、化学分析等。（3）负载平衡。即把负载压力根据某种算法合理分配到集群中的每一台计算机上，以减轻主服务器的压力，降低对主服务器的硬件和软件要求。集群系统一般应具高可用性、可伸缩性、负载均衡、故障恢复和可维护性等特殊性能。 高可用性是集群系统最基本的要求，它是对整个系统运行稳定性的一个评价。可伸缩性是指整个系统在随着客户端用户数量的增加而继续保持有效响应时间的能力。在 一个可伸缩性系统中，随着用户数量的增加，有效响应时间变长，成线性变化关系，这也体现一个系统的峰值负载处理能力，但随着越来越多的系统处于Internet上， 用户访问的峰值负载有效预测已变的不可能。用户访问量的猛增，使系统的有效响应时间成非线性变化，响应时间急剧变长，知道系统不堪重负而停机。一般的解决 方法就是通过提升系统硬件系统，或通过增加服务器。但是不合理的增加服务器只能使整个集群系统变的越来越庞大，系统的这种复杂化就意味系统故障率变高，随 之整个系统可靠性、可维护性都会降低。3.1负载均衡(Load Balance)Load Balance 主要的目的在于将访问系统的负荷分散在不同的机器上，使整个系统吞吐量和并发性得到提高, 它能让多台服务器共同承担一些繁重的计算或I/O任务，从而消除网络瓶颈，提高网络的灵活性和可靠性。常见的方法如下：l 循环DNSDNS负载均衡是一种简单而有效的方法，该方法使用简单的域名查询IP地址来实现一种简单的负载均衡。任意给出一个地址，DNS服务器都有一个IP地址池与之对应。每次请求将域名转换成IP地址时，循环返回IP地址池中的下一个地址。故被称作DNS round-robin。当一个Client访问时，给请求JNDI的InitialContext客户端传递一个DNS名，作为命名服务器的URL，每个DNS名字被转换成一个不同的地址，使用这个技术，每个客户端InitailContext请求就被直接发送到不同的服务器上。 负载均衡的一大缺点是：一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间（因为DNS需要一定的刷新时间）才能发挥作用，在此期间，有些客户端用户访问仍旧将发送故障服务器上。l 软件Proxy软件Proxy维护连接到一系列服务器上的打开连接。当一个Client访问服务器时，先要经过这个软件代理，这个代理能通过一些负载均衡的算法（如采用类似DNS Round-robin、随机方法、访问权衡算法 ）把一个用户的访问重新定向到一个服务器。这个软件代理方法能够及时发现服务器死机或没有响应，有效地避免了DNS round-robin方法中出现地故障访问。l 硬件均衡器 这种硬件均衡器一般采用地址转换技术，将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。一般可采用第四层（或4层以上）的交换机来实现，这种交换机是按照IP地址和TCP端口进行虚拟连接的交换，直接将数据包发送到目的计算机的相应端口。通过交换机就能将来自外部的初始连接请求，分别与内部的多个地址相联系，从而建立虚拟连接实现负载均衡。这种第四层交换基于硬件芯片，因此网络传输速度和交换速度远远超过普通软件代理方式。如采用Cisco CSS 11150（一种L4 Switch）可以实现硬件均衡。来自 /blog/112997 /zh/lvs4.html /blog/60873 软件设计的原则1、基于request的负载均衡 该种方式下，负载均衡器 (load balancer)会根据各个node的状况，把每个http request进行分发。使用这样的均衡策略，就必须在多个node之间复制用户的session，实时保持整个cluster的用户状态同步，这种操作被称为session复制 (session replication)。Jboss的实现原理是使用拦截器(interceptor)，根据用户的同步策略拦截request，做同步处理后再交给server产生响应。该方法的优点是客户不会被绑定都具体的node，只要还有一个node存活，用户状态都不会丢失，cluster都能够继续工作。缺点是node之间通信频繁，响应速度有影响，多并发、高频操作的情况下性能下降比较厉害。2、基于用户的负载均衡该种方式下，当用户发出第一个request后，负载均衡器动态的把该用户分配到某个节点，并记录该节点的jvm路由，以后该用户的所有request都会被绑定这个jvm路由，用户只会与该server发生交互，这种策略被称为粘性session(session sticky)。该方法的优点是响应速度快，多个节点之间无须通信。缺点也很明显，某个node死掉以后，它负责的所有用户都会丢失session。一、Cache分类TreeCache按功能分为三类：本地(Local)Cache、复制(Replication)Cache和失效(Invalidation)Cache。本地Cache只应用于本地环境，后两个Cache可应用于分布式环境，其中，在分布式环境中，复制Cache当一个Cache实例的一个节点值发生变化时会将变化复制到其它实例中，而失效Cache是当一个Cache实例的一个节点值发生变化时会将其它实例的相应节点的值设为空，让其重新去获得该值，可通过这种方式缓存大对象以减少在实例中复制对象的代价。分布式Cache（复制和失效Cache）又分为两种，同步（REPL_ASYNC）和异步（REPL_SYNC），同步Cache是在一个Cache实例做修改时，等待变化应用到其它实例后才返回，而异步Cache是在一个Cache实例做修改时，即刻返回。其配置见下：18REPL_SYNC二、事务和并行(TransactionAndConcurrent)optimistic-lock属性有如下可选取值： ? none 无乐观锁 ? version 通过版本机制实现乐观锁 ? dirty 通过检查发生变动过的属性实现乐观锁 ? all 通过检查所有属性实现乐TreeCache是一种事务Cache，与JDBC一样，其包括两方面内容：锁和隔离级别。锁分为悲观锁和乐观锁，当使用悲观锁时，分为五个隔离级别，分别是SERIALIZABLE、REPEATABLE_READ(default)、READ_COMMITTED、READ_UNCOMMITTED和NONE，隔离级别逐步减弱。乐观锁也叫版本锁，其对数据进行操作时，将其复制到临时区，操作之后将版本与原有数据比较，如果一致则将递增版本并写回，如果不一致则回滚，由于乐观锁仅在复制出数据和提交数据时对数据加锁，所以并行度更高，但如果写操作比较频繁地话则容易出现冲突导致回滚。TreeCache默认使用悲观锁。使用TreeCache时，需要使用容器提供的事务管理器，一般使JBossTransactionManagerLookup和GenericTransactionManagerLookup，前者应用于JBOSS服务器，后者应用于其他服务器，也可使用DummyTransactionManagerLookup用于测试。如上介绍的配置如下：1OPTIMISTIC2REPEATABLE_READ3org.jboss.cache.DummyTransactionManagerLookup45三、逐出策略(EvictionPolicy)由于内存数量的局限，不可能将所有的Cache数据存放在内存中，但使用内存达到一定极限时，会将部分数据清除出内存，保存到其它持久媒质中，定义的什么时候清除、如何清除的策略就是逐出策略。自定义一个逐出策略需要实现org.jboss.cache.eviction.EvictionPolicy、org.jboss.cache.eviction.EvictionAlgorithm、org.jboss.cache.eviction.EvictionQueue和org.jboss.cache.eviction.EvictionConfiguration四个接口，系统提供了LRU(Leastrecentlyused，最近最少使用)、LFU(LeastFrequentlyUsed最不经常使用)、FIFO(FirstInFirstOut先进先出)、MRU(MostRecentlyUsed最近最经常使用)四种实现，详细参见org.jboss.cache.eviction包的源代码。配置如下：1235455000610007810500011121310000141516100001781810192021Hibernate 缓存很多人对二级缓存都不太了解，或者是有错误的认识，我一直想写一篇文章介绍一下hibernate的二级缓存的，今天终于忍不住了。 我的经验主要来自hibernate2.1版本，基本原理和3.0、3.1是一样的，请原谅我的顽固不化。hibernate的session提供了一级缓存，每个session，对同一个id进行两次load，不会发送两条sql给数据库，但是session关闭的时候，一级缓存就失效了。二级缓存是SessionFactory级别的全局缓存，它底下可以使用不同的缓存类库，比如ehcache、oscache等，需要设置vider_class，我们这里用ehcache，在2.1中就是 vider_class=net.sf.hibernate.cache.EhCacheProvider 如果使用查询缓存，加上 hibernate.cache.use_query_cache=true缓存可以简单的看成一个Map，通过key在缓存里面找value。Class的缓存 对于一条记录，也就是一个PO来说，是根据ID来找的，缓存的key就是ID，value是POJO。无论list，load还是 iterate，只要读出一个对象，都会填充缓存。但是list不会使用缓存，而iterate会先取数据库select id出来，然后一个id一个id的load，如果在缓存里面有，就从缓存取，没有的话就去数据库load。假设是读写缓存，需要设置： 如果你使用的二级缓存实现是ehcache的话，需要配置ehcache.xml 其中eternal表示缓存是不是永远不超时，timeToLiveSeconds是缓存中每个元素（这里也就是一个POJO）的超时时间，如果 eternal=false，超过指定的时间，这个元素就被移走了。timeToIdleSeconds是发呆时间，是可选的。当往缓存里面put 的元素超过500个时，如果overflowToDisk=true，就会把缓存中的部分数据保存在硬盘上的临时文件里面。 每个需要缓存的class都要这样配置。如果你没有配置，hibernate会在启动的时候警告你，然后使用defaultCache的配置，这样多个class会共享一个配置。 当某个ID通过hibernate修改时，hibernate会知道，于是移除缓存。 这样大家可能会想，同样的查询条件，第一次先list，第二次再iterate，就可以使用到缓存了。实际上这是很难的，因为你无法判断什么时候是第一次，而且每次查询的条件通常是不一样的，假如数据库里面有100条记录，id从1到100，第一次list的时候出了前50个id，第二次 iterate的时候却查询到30至70号id，那么30-50是从缓存里面取的，51到70是从数据库取的，共发送1+20条sql。所以我一直认为 iterate没有什么用，总是会有1+N的问题。 （题外话：有说法说大型查询用list会把整个结果集装入内存，很慢，而iterate只select id比较好，但是大型查询总是要分页查的，谁也不会真的把整个结果集装进来，假如一页20条的话，iterate共需要执行21条语句，list虽然选择若干字段，比iterate第一条select id语句慢一些，但只有一条语句，不装入整个结果集hibernate还会根据数据库方言做优化，比如使用mysql的limit，整体看来应该还是 list快。） 如果想要对list或者iterate查询的结果缓存，就要用到查询缓存了查询缓存 查询的结果集也可以被缓存。只有当经常使用同样的参数进行查询时，这才会有些用处。 要使用查询缓存，首先你必须打开它： 该设置将会创建两个缓存区域 - 一个用于保存查询结果集(org.hibernate.cache.StandardQueryCache)； 另一个则用于保存最近查询的一系列表的时间戳(org.hibernate.cache.UpdateTimestampsCache)。 请注意：在查询缓存中，它并不缓存结果集中所包含的实体的确切状态；它只缓存这些实体的标识符属性的值、以及各值类型的结果。 所以查询缓存通常会和二级缓存一起使用。 绝大多数的查询并不能从查询缓存中受益，所以Hibernate默认是不进行查询缓存的。如若需要进行缓存，请调用 Query.setCacheable(true)方法。这个调用会让查询在执行过程中时先从缓存中查找结果， 并将自己的结果集放到缓存中去。 首先需要配置hibernate.cache.use_query_cache=true 如果用ehcache，配置ehcache.xml，注意hibernate3.0以后不是net.sf的包名了 然后 query.setCacheable(true);/激活查询缓存 query.setCacheRegion(myCacheRegion);/指定要使用的cacheRegion，可选 第二行指定要使用的cacheRegion是myCacheRegion，即你可以给每个查询缓存做一个单独的配置，使用setCacheRegion来做这个指定，需要在ehcache.xml里面配置它： 如果省略第二行，不设置cacheRegion的话，那么会使用上面提到的标准查询缓存的配置，也就是net.sf.hibernate.cache.StandardQueryCache对于查询缓存来说，缓存的key是根据hql生成的sql，再加上参数，分页等信息（可以通过日志输出看到，不过它的输出不是很可读，最好改一下它的代码）。 比如hql： from Cat c where like ? 生成大致如下的sql： select * from cat c where like ? 参数是tiger%，那么查询缓存的key*大约*是这样的字符串（我是凭记忆写的，并不精确，不过看了也该明白了）： select * from cat c where like ? , parameter:tiger% 这样，保证了同样的查询、同样的参数等条件下具有一样的key。 现在说说缓存的value，如果是list方式的话，value在这里并不是整个结果集，而是查询出来的这一串ID。也就是说，不管是list方法还是 iterate方法，第一次查询的时候，它们的查询方式很它们平时的方式是一样的，list执行一条sql，iterate执行1+N条，多出来的行为是它们填充了缓存。但是到同样条件第二次查询的时候，就都和iterate的行为一样了，根据缓存的key去缓存里面查到了value，value是一串 id，然后在到class的缓存里面去一个一个的load出来。这样做是为了节约内存。 可以看出来，查询缓存需要打开相关类的class缓存。list和iterate方法第一次执行的时候，都是既填充查询缓存又填充class缓存的。 这里还有一个很容易被忽视的重要问题，即打开查询缓存以后，即使是list方法也可能遇到1+N的问题！相同条件第一次list的时候，因为查询缓存中找不到，不管class缓存是否存在数据，总是发送一条sql语句到数据库获取全部数据，然后填充查询缓存和class 缓存。但是第二次执行的时候，问题就来了，如果你的class缓存的超时时间比较短，现在class缓存都超时了，但是查询缓存还在，那么list方法在获取id串以后，将会一个一个去数据库load！因此，class缓存的超时时间一定不能短于查询缓存设置的超时时间！如果还设置了发呆时间的话，保证 class缓存的发呆时间也大于查询的缓存的生存时间。这里还有其他情况，比如class缓存被程序强制evict了，这种情况就请自己注意了。另外，如果hql查询包含select字句，那么查询缓存里面的value就是整个结果集了。当hibernate更新数据库的时候，它怎么知道更新哪些查询缓存呢？ hibernate在一个地方维护每个表的最后更新时间，其实也就是放在上面net.sf.hibernate.cache.UpdateTimestampsCache所指定的缓存配置里面。 当通过hibernate更新的时候，hibernate会知道这次更新影响了哪些表。然后它更新这些表的最后更新时间。每个缓存都有一个生成时间和这个缓存所查询的表，当hibernate查询一个缓存是否存在的时候，如果缓存存在，它还要取出缓存的生成时间和这个缓存所查询的表，然后去查找这些表的最后更新时间，如果有一个表在生成时间后更新过了，那么这个缓存是无效的。 可以看出，只要更新过一个表，那么凡是涉及到这个表的查询缓存就失效了，因此查询缓存的命中率可能会比较低。Collection缓存 需要在hbm的collection里面设置 假如class是Cat，collection叫children，那么ehcache里面配置 Collection的缓存和前面查询缓存的list一样，也是只保持一串id，但它不会因为这个表更新过就失效，一个collection缓存仅在这个collection里面的元素有增删时才失效。 这样有一个问题，如果你的collection是根据某个字段排序的，当其中一个元素更新了该字段时，导致顺序改变时，collection缓存里面的顺序没有做更新。缓存策略 只读缓存（read-only）：没有什么好说的 读/写缓存（read-write）:程序可能要的更新数据 不严格的读/写缓存（nonstrict-read-write）：需要更新数据，但是两个事务更新同一条记录的可能性很小，性能比读写缓存好 事务缓存（transactional）：缓存支持事务，发生异常的时候，缓存也能够回滚，只支持jta环境，这个我没有怎么研究过读写缓存和不严格读写缓存在实现上的区别在于，读写缓存更新缓存的时候会把缓存里面的数据换成一个锁，其他事务如果去取相应的缓存数据，发现被锁住了，然后就直接取数据库查询。 在hibernate2.1的ehcache实现中，如果锁住部分缓存的事务发生了异常，那么缓存会一直被锁住，直到60秒后超时。 不严格读写缓存不锁定缓存中的数据。使用二级缓存的前置条件 你的hibernate程序对数据库有独占的写访问权，其他的进程更新了数据库，hibernate是不可能知道的。你操作数据库必需直接通过 hibernate，如果你调用存储过程，或者自己使用jdbc更新数据库，hibernate也是不知道的。hibernate3.0的大批量更新和删除是不更新二级缓存的，但是据说3.1已经解决了这个问题。 这个限制相当的棘手，有时候hibernate做批量更新、删除很慢，但是你却不能自己写jdbc来优化，很郁闷吧。 Sessio