单系统缓存改成集群
1、TreeCache / JBossCache
JBossCache是一个复制的事务处理缓存，它允许你缓存企业级应用数据来更好的改善性能。缓存数据被自动复制，让你轻松进行JBoss服务器之间 的集群工作。JBossCache能够通过JBoss应用服务或其他J2EE容器来运行一个MBean服务，当然，它也能独立运行。
2、WhirlyCache
Whirlycache是一个快速的、可配置的、存在于内存中的对象的缓存。它能够通过缓存对象来加快网站或应用程序的速度，否则就必须通过查询数据库或其他代价较高的处理程序来建立。
3、SwarmCache
SwarmCache是一个简单且有效的分布式缓存，它使用IP multicast与同一个局域网的其他主机进行通讯，是特别为集群和数据驱动web应用程序而设计的。SwarmCache能够让典型的读操作大大超过写操作的这类应用提供更好的性能支持。
4、JCache
JCache是个开源程序，正在努力成为JSR-107开源规范，JSR-107规范已经很多年没改变了。这个版本仍然是构建在最初的功能定义上。
5、ShiftOne
ShiftOne Java Object Cache是一个执行一系列严格的对象缓存策略的Java lib，就像一个轻量级的配置缓存工作状态的框架。
⑵ 如何设置系统缓存和虚拟内存
建议不要修改这个，用处不大。
首先，一般优化来说，虚拟内存是物理内存的2倍比较合适。我原来也是1G内存，后来发现占用太多了虚拟内存硬盘了，减少到512M内存使用了。如果你机器不是用来跑大软件，那么多内存也用不上的。
最好就是windows自己管理虚拟内存。
⑶ linux redis 怎么设置集群
redis.conf 配置文件说明
daemonize no --是否把redis-server启动在后台，默认是“否”。若改成yes
pidfile /var/run/redis.pid --当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
prot 6379 --指定Redis监听端口，默认端口为6379
bind 10.252.1.14 ---绑定的主机地址
timeout 0 ---当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
loglevel notice ---指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
logfile /mnt/redis/log/redis.log --日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
databases 16 设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
save 900 1 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
Redis默认配置文件中提供了三个条件：
save 900 1
save 300 10
save 60 10000
分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改
rdbcompression yes --指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
dbfilename mp.rdb --指定本地数据库文件名，默认值为mp.rdb
dir /mnt/redis/data/ --指定本地数据库存放目录
slaveof <masterip> <masterport> -- 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
masterauth <master-password> --当master服务设置了密码保护时，slav服务连接master的密码
requirepass foobared --设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
maxclients 128 --- 设置同一时间最大客户端连接数，默认无限制
maxmemory <bytes> ---指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
appendonly no --指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
appendfilename appendonly.aof ---指定更新日志文件名，默认为appendonly.aof
appendfsync everysec ---指定更新日志条件，共有3个可选值： no：表示等操作系统进行数据缓存同步到磁盘（快） . always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）. everysec：表示每秒同步一次（折衷，默认值）
vm-enabled no ---指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
vm-swap-file /tmp/redis.swap ---虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
vm-max-memory 0 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
vm-page-size 32 ---Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
vm-pages 134217728 ---设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
vm-max-threads 4 ---设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
glueoutputbuf yes ---设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
hash-max-zipmap-entries 64 ---指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
hash-max-zipmap-value 512 ---指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
activerehashing yes ---指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
include /path/to/local.conf ---指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
主服务器配置
mkdir /mnt/redis/redisDB
mkdir /mnt/redis/redisLog
vi /etc/redis/redis.conf
dbfilename /mnt/redisDB/mp.rdb --修改磁盘上保存数据库文件的位置
loglevel warning --修改日志级别
logfile /mnt/redis/redisLog/redis.log --修改日志文件的位置
从机配置
cp redis.conf /etc/redis_slave.conf
vim redis_slave.conf
修改其中的一行
配置master的ip地址和redis-server的端口。
slaveof <10.45.39.39> <6379> --设置主从服务器的主服务器的地址和端口
daemonize no --是否把redis-server启动在后台，默认是“否”。若改成yes，会生成一个pid文件。
主从测试
主机: redis-server /etc/redis.conf
从机: redis-server /etc/redis_slave.conf
3.1 测试
在主机上启动redis客户端:
ssh 192.168.1.1
redis-cli
>set k1 v1
>get k1
"v1"
.登陆从机，并在从机上启动客户端：
ssh 192.168.1.2
redis-cli
>get k1
"v1"
可以看到redis已经把数据同步过来了。
⑷ 如何对局域网内的多台Linux进行集群化管理
它非常适合用来快速配置一个集群中的所有运行相同服务和具备相同配置的计算机节点。现在有大量的开源管理工具，都可以实现这样的管理，比如dsh、SUSE Manager等。下面是用ClusterSSH管理多台Linux服务器的具体过程。
如果你是一名Linux系统管理员，那你每天一定会和许许多多的机器打交道，因为你要定期监测和维护这些机器，如一批Web服务器，如果你要同时在多台机器上敲入相同的命令，你可能会通过SSH登录，然后逐台敲入，如果使用ClusterSSH，可以为你节省不少类似的工作时间。
ClusterSSH是用Tk/Perl包装XTerm和SSH后形成的新工具，就其本身而言，它可以运行在任何兼容POSIX的操作系统上，我曾经在Linux，Solaris和Mac OS X上运行过它，它需要Perl库Tk（在Debian或Ubuntu上就是perl-tk）和X11::Protocol（在Debian或Ubuntu上就是libx11-protocol-perl），此外，xterm和OpenSSH是必不可少的。
安装在Debian或Ubuntu上安装ClusterSSH是相当简单的，只需要敲入sudo apt-get install clusterssh就可以安装好，至于依赖包你也不必担心，一切都会为你装好的，它也提供了适合Fedora的rpm包，在FreeBSD上可通过port系统安装，还为Mac OS X准备了MacPort版本，因此你可以在你的苹果电脑上安装ClusterSSH，当然，如果你是极客，也可以下载源代码自己编译。
配置可以通过ClusterSSH的全局配置文件/etc/clusters，或用户home目录下的。csshrc文件来配置它，我喜欢用户级的配置方式，这样同一个系统中的不同用户可以根据自己的喜好进行配置，ClusterSSH定义了一个“cluster”机器组，你可以通过一个界面来控制这个组中的所有机器，在配置文件的顶端“clusters”部分，你可以详尽地列出你的集群，然后用独立的段落来描述每个集群。
例如，假设我有两个集群，每个集群由两台机器组成，“Cluster1”由“Test1”和“Test2”两台机器组成，“Cluster2”由“Test3”和“Test4”两台机器组成，~.csshrc（或/etc/clusters）配置文件的内容看起来应该是：
clusters = cluster1 cluster2
cluster1 = test1 test2
cluster2 = test3 test4你也可以创建中间集群（包含其它集群的集群），如果你想创建一个名叫“all”的集群包含所有的机器，有两种实现手段，首先，你可以创建一个包含所有机器的集群，如：
clusters = cluster1 cluster2 all
cluster1 = test1 test2
cluster2 = test3 test4
all = test1 test2 test3 test4但我更喜欢的方法是使用一个包含其它集群的中间集群：
clusters = cluster1 cluster2 allcluster1 = test1 test2
⑸ 怎么把系统缓存设到D盘怎么把D盘的内存转到C盘
C盘和D盘是电脑的概念，电脑的盘是硬盘，不是内存。移动的操作是非常简单的。
1、到D盘，找到要移动的文件，按键盘ctrl+X。
2、到C盘，找到目标文件夹，点击进入，按键盘的ctrl+V。文件就过去了。
3、也可以用菜单来操作。到D盘找到文件，点工具栏里的剪切，或右键点击它选剪切，然后到目标文件夹里，在空白处，点工具栏里的粘贴，或右键选粘贴。
剪切和粘贴，这是电脑的最基本的操作。
⑹ Redis集群方案应该怎么做
通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？
首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。
其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。
方案
1.Redis官方集群方案 Redis Cluster
Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。
Redis
Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类似前面讲的pre
sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简
单，就是CRC16后16384取模。
Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个
slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实
现中，还处于半自动状态，需要人工介入。
Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。
为
了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失
效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似前篇文章提到的Redis
Sharding场景下服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。
Redis
Cluster的新节点识别能力、故障判断及故障转移能力是通过集群中的每个node都在和其它nodes进行通信，这被称为集群总线(cluster
bus)。它们使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是
16379。nodes之间的通信采用特殊的二进制协议。
对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个
node进行操作，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这
有点儿像浏览器页面的302 redirect跳转。
Redis Cluster是Redis 3.0以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。
2.Redis Sharding集群
Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。
多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。
Redis
Sharding可以说是Redis
Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定
的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点操作数据。Sharding架构如图：
庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。
Jedis的Redis Sharding实现具有如下特点：
采
用一致性哈希算法(consistent
hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类
似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。
2.
为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟
化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点
时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。
3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。
Redis Sharding采用客户端Sharding方式，服务端Redis还是一个个相对独立的Redis实例节点，没有做任何变动。同时，我们也不需要增加额外的中间处理组件，这是一种非常轻量、灵活的Redis多实例集群方法。
当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。
作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。有没有其它手段改善这种情况？
Redis
作者给出了一个比较讨巧的办法--presharding，即预先根据系统规模尽量部署好多个Redis实例，这些实例占用系统资源很小，一台物理机可部
署多个，让他们都参与sharding，当需要扩容时，选中一个实例作为主节点，新加入的Redis节点作为从节点进行数据复制。数据同步后，修改
sharding配置，让指向原实例的Shard指向新机器上扩容后的Redis节点，同时调整新Redis节点为主节点，原实例可不再使用。
presharding
是预先分配好足够的分片，扩容时只是将属于某一分片的原Redis实例替换成新的容量更大的Redis实例。参与sharding的分片没有改变，所以也
就不存在key值从一个区转移到另一个分片区的现象，只是将属于同分片区的键值从原Redis实例同步到新Redis实例。
并不是只有增
删Redis节点引起键值丢失问题，更大的障碍来自Redis节点突然宕机。在《Redis持久化》一文中已提到，为不影响Redis性能，尽量不开启
AOF和RDB文件保存功能，可架构Redis主备模式，主Redis宕机，数据不会丢失，备Redis留有备份。
这样，我们的架构模式变
成一个Redis节点切片包含一个主Redis和一个备Redis。在主Redis宕机时，备Redis接管过来，上升为主Redis，继续提供服务。主
备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性。则Sharding架构演变成：
Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。
高访问量下，即使采用Sharding分片，一个单独节点还是承担了很大的访问压力，这时我们还需要进一步分解。通常情况下，应用访问Redis读操作量和写操作量差异很大，读常常是写的数倍，这时我们可以将读写分离，而且读提供更多的实例数。
可以利用主从模式实现读写分离，主负责写，从负责只读，同时一主挂多个从。在Sentinel监控下，还可以保障节点故障的自动监测。
3.利用代理中间件实现大规模Redis集群
上面分别介绍了多Redis服务器集群的两种方式，它们是基于客户端sharding的Redis Sharding和基于服务端sharding的Redis Cluster。
客户端sharding技术其优势在于服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。其不足之处在于：
由于sharding处理放到客户端，规模进步扩大时给运维带来挑战。
服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。
连接不能共享，当应用规模增大时，资源浪费制约优化。
服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时，客户端不需要感知，客户端像使用单Redis服务器一样使用Redis集群，运维管理也比较方便。
不过Redis Cluster正式版推出时间不长，系统稳定性、性能等都需要时间检验，尤其在大规模使用场合。
能不能结合二者优势？即能使服务端各实例彼此独立，支持线性可伸缩，同时sharding又能集中处理，方便统一管理？本篇介绍的Redis代理中间件twemproxy就是这样一种利用中间件做sharding的技术。
twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后(如sharding)，再转发给后端真正的Redis服务器。也就是说，客户端不直接访问Redis服务器，而是通过twemproxy代理中间件间接访问。
参照Redis Sharding架构，增加代理中间件的Redis集群架构如下：
twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可避免单点压力或故障。
twemproxy又叫nutcracker，起源于twitter系统中redis/memcached集群开发实践，运行效果良好，后代码奉献给开源社区。其轻量高效，采用C语言开发，工程网址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis
twemproxy后端不仅支持redis，同时也支持memcached，这是twitter系统具体环境造成的。
由于使用了中间件，twemproxy可以通过共享与后端系统的连接，降低客户端直接连接后端服务器的连接数量。同时，它也提供sharding功能，支持后端服务器集群水平扩展。统一运维管理也带来了方便。
当然，也是由于使用了中间件代理，相比客户端直连服务器方式，性能上会有所损耗，实测结果大约降低了20%左右。
⑺ hibernate使用memcached作为二级缓存，怎么构建memcached集群
redis是一个key-value存储系统和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。
与memcached一样，为了保证效率，数据都是缓存在内存中。
区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。