㈠ 如何解决高并发场景下，缓存冷启动导致mysql负载过高，甚至瞬间被打死的问题
由于mysql是一个连接给一个线程，当并发高的时候，每秒需要几百个甚至更多的线程，其中创建和销毁线程还好说，大不了多耗费点内存，线程缓存命中率下降还有创建销毁线程的性能增加问题---这个问题不是特别大，重点是mysql底层瞬间处理这几百个线程提交的sql（有时候一个页面会有10多条sql，cpu一次只能处理一条sql）会导致cpu的上下文切换，性能抖动，然后性能下降。
㈡ 高性能高并发网站架构，教你搭建Redis5缓存集群
一、Redis集群介绍
Redis真的是一个优秀的技术，它是一种key-value形式的NoSQL内存数据库，由ANSI C编写，遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。 Redis最大的特性是它会将所有数据都放在内存中，所以读写速度性能非常好。Redis是基于内存进行操作的，性能较高，可以很好的在一定程度上解决网站一瞬间的并发量，例如商品抢购秒杀等活动。
网站承受高并发访问压力的同时，还需要从海量数据中查询出满足条件的数据，需要快速响应，前端发送请求、后端和mysql数据库交互，进行sql查询操作，读写比较慢，这时候引入Redis ,把从mysql 的数据缓存到Redis 中，下次读取时候性能就会提高；当然，它也支持将内存中的数据以快照和日志的形式持久化到硬盘，这样即使在断电、机器故障等异常情况发生时数据也不会丢失，Redis能从硬盘中恢复快照数据到内存中。
Redis 发布了稳定版本的 5.0 版本，放弃 Ruby的集群方式，改用 C语言编写的 redis-cli的方式，是集群的构建方式复杂度大大降低。Redis-Cluster集群采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。
为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。
redis-cluster投票:容错，投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉。
集群中至少应该有奇数个节点，所以至少有三个节点，每个节点至少有一个备份节点，所以下面使用6节点（主节点、备份节点由redis-cluster集群确定）。6个节点分布在一台机器上，采用三主三从的模式。实际应用中，最好用多台机器，比如说6个节点分布到3台机器上，redis在建立集群时为自动的将主从节点进行不同机器的分配。
二、单机redis模式
下载源码redis5.0并解压编译
wget http://download.redis.io/releases/redis-5.0.0.tar.gz
tar xzf redis-5.0.0.tar.gz
cd redis-5.0.0
make
redis前端启动需要改成后台启动.
修改redis.conf文件,将daemonize no -> daemonize yes
vim redis.conf
启动redis
/www/server/redis/src/redis-server /www/server/redis/redis.conf
查看redis是否在运行
ps aux|grep redis
现在是单机redis模式完成。
三、redis集群模式：
1.创建6个Redis配置文件
cd /usr/local/
mkdir redis_cluster //创建集群目录
cd redis_cluster
mkdir 7000 7001 7002 7003 7004 7005//分别代表6个节点
其对应端口 7000 7001 7002 70037004 7005
2.复制配置文件到各个目录
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7000/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7001/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7002/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7003/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7004/
cp /www/server/redis/redis.conf /usr/local/redis_cluster/7005/
3.分别修改配置文件
vim /usr/local/redis_cluster/7000/redis.conf
vim /usr/local/redis_cluster/7001/redis.conf
vim /usr/local/redis_cluster/7002/redis.conf
vim /usr/local/redis_cluster/7003/redis.conf
vim /usr/local/redis_cluster/7004/redis.conf
vim /usr/local/redis_cluster/7005/redis.conf
如下
port 7000 #端口
cluster-enabled yes #启用集群模式
cluster-config-file nodes_7000.conf ＃集群的配置 配置文件首次启动自动生成
cluster-node-timeout 5000 #超时时间 5秒
appendonly yes ＃aof日志开启 它会每次写操作都记录一条日志
daemonize yes #后台运行
protected-mode no #非保护模式
pidfile /var/run/redis_7000.pid
//下面可以不写
#若设置密码，master和slave需同时配置下面两个参数：
masterauth "jijiji" #连接master的密码
requirepass "jijiji" #自己的密码
cluster-config-file，port，pidfile对应数字
4.启动节点
cd /www/server/redis/src/
./redis-server /usr/local/redis_cluster/7000/redis.conf
./redis-server /usr/local/redis_cluster/7001/redis.conf
./redis-server /usr/local/redis_cluster/7002/redis.conf
./redis-server /usr/local/redis_cluster/7003/redis.conf
./redis-server /usr/local/redis_cluster/7004/redis.conf
./redis-server /usr/local/redis_cluster/7005/redis.conf
查看redis运行
ps aux|grep redis
5.启动集群
/www/server/redis/src/redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
这里使用的命令是create，因为我们要创建一个新的集群。 该选项--cluster-replicas 1意味着我们希望每个创建的主服务器都有一个从服。
输入yes
至此，Reids5 集群搭建完成。
6.检查Reids5集群状态
可以执行redis-cli --cluster check host:port检查集群状态slots详细分配。
redis-cli --cluster info 127.0.0.1:7000
7.停止Reids5集群
（1）.因为Redis可以妥善处理SIGTERM信号，所以直接kill -9也是可以的，可以同时kill多个,然后再依次启动。
kill -9 PID PID PID
（2）.redis5 提供了关闭集群的工具，修改文件： /www/server/redis/utils/create-cluster/create-cluster
端口PROT设置为6999，NODES为6，工具会生成 7000-7005 六个节点 用于操作。
修改后，执行如下命令关闭集群：
/www/server/redis/utils/create-cluster/create-cluster stop
重新启动集群：
/www/server/redis/utils/create-cluster/create-cluster start
8.帮助信息
执行redis-cli --cluster help,查看更多帮助信息
redis-cli --cluster help
吉海波
㈢ 分布式缓存主要用在高并发环境下的作用
分布式缓存主要用在高并发环境下，减轻数据库的压力，提高系统的响应速度和并发吞吐。当大量的读、写请求涌向数据库时，磁盘的处理速度与内存显然不在一个量级，因此，在数据库之前加一层缓存，能够显着提高系统的响应速度，并降低数据库的压力。作为传统的关系型数据库，MySQL提供完整的ACID操作，支持丰富的数据类型、强大的关联查询、where语句等，能够非常客易地建立查询索引，执行复杂的内连接、外连接、求和、排序、分组等操作，并且支持存储过程、函数等功能，产品成熟度高，功能强大。但是，对于需要应对高并发访问并且存储海量数据的场景来说，出于对性能的考虑，不得不放弃很多传统关系型数据库原本强大的功能，牺牲了系统的易用性，并且使得系统的设计和管理变得更为复杂。这也使得在过去几年中，流行着另一种新的存储解决方案——NoSQL，它与传统的关系型数据库最大的差别在于，它不使用SQL作为查询语言来查找数据，而采用key-value形式进行查找，提供了更高的查询效率及吞吐，并且能够更加方便地进行扩展，存储海量数据，在数千个节点上进行分区，自动进行数据的复制和备份。在分布式系统中，消息作为应用间通信的一种方式，得到了十分广泛的应用。消息可以被保存在队列中，直到被接收者取出，由于消息发送者不需要同步等待消息接收者的响应，消息的异步接收降低了系统集成的耦合度，提升了分布式系统协作的效率，使得系统能够更快地响应用户，提供更高的吞吐。
当系统处于峰值压力时，分布式消息队列还能够作为缓冲，削峰填谷，缓解集群的压力，避免整个系统被压垮。垂直化的搜索引擎在分布式系统中是一个非常重要的角色，它既能够满足用户对于全文检索、模糊匹配的需求，解决数据库like查询效率低下的问题，又能够解决分布式环境下，由于采用分库分表，或者使用NoSQL数据库，导致无法进行多表关联或者进行复杂查询的问题。
㈣ 高并发，写入频繁的评论系统有必要加缓存么
如果并发真到几万的话，缓存肯定是要加的。
具体加缓存的策略，看想要什么效果，可以对查询最频繁的一类请求先加缓存。
保证mongo处于一个合理的负载。
㈤ 高并发处理的几种方法
一、将数据存到redis缓存
二、使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器.
三、使用Ngnix负载均衡
㈥ 华为技术架构师分享：高并发场景下缓存处理的一些思路
在实际的开发当中，我们经常需要进行磁盘数据的读取和搜索，因此经常会有出现从数据库读取数据的场景出现。但是当数据访问量次数增大的时候，过多的磁盘读取可能会最终成为整个系统的性能瓶颈，甚至是压垮整个数据库，导致系统卡死等严重问题。
常规的应用系统中，我们通常会在需要的时候对数据库进行查找，因此系统的大致结构如下所示：
1.缓存和数据库之间数据一致性问题
常用于缓存处理的机制我总结为了以下几种：
首先来简单说说Cache aside的这种方式：
Cache Aside模式
这种模式处理缓存通常都是先从数据库缓存查询，如果缓存没有命中则从数据库中进行查找。
这里面会发生的三种情况如下：
缓存命中：
当查询的时候发现缓存存在，那么直接从缓存中提取。
缓存失效：
当缓存没有数据的时候，则从database里面读取源数据，再加入到cache里面去。
缓存更新：
当有新的写操作去修改database里面的数据时，需要在写操作完成之后，让cache里面对应的数据失效。
关于这种模式下依然会存在缺陷。比如，一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。
Facebook的大牛们也曾经就缓存处理这个问题发表过相关的论文，链接如下:
分布式环境中要想完全的保证数据一致性是一件极为困难的事情，我们只能够尽可能的减低这种数据不一致性问题产生的情况。
Read Through模式
Read Through模式是指应用程序始终从缓存中请求数据。 如果缓存没有数据，则它负责使用底层提供程序插件从数据库中检索数据。 检索数据后，缓存会自行更新并将数据返回给调用应用程序。使用Read Through 有一个好处。
我们总是使用key从缓存中检索数据, 调用的应用程序不知道数据库， 由存储方来负责自己的缓存处理，这使代码更具可读性， 代码更清晰。但是这也有相应的缺陷，开发人员需要给编写相关的程序插件，增加了开发的难度性。
Write Through模式
Write Through模式和Read Through模式类似，当数据发生更新的时候，先去Cache里面进行更新，如果命中了，则先更新缓存再由Cache方来更新database。如果没有命中的话，就直接更新Cache里面的数据。
2.缓存穿透问题
在高并发的场景中，缓存穿透是一个经常都会遇到的问题。
什么是缓存穿透？
大量的请求在缓存中没有查询到指定的数据，因此需要从数据库中进行查询，造成缓存穿透。
会造成什么后果？
大量的请求短时间内涌入到database中进行查询会增加database的压力，最终导致database无法承载客户单请求的压力，出现宕机卡死等现象。
常用的解决方案通常有以下几类：
1.空值缓存
在某些特定的业务场景中，对于数据的查询可能会是空的，没有实际的存在，并且这类数据信息在短时间进行多次的反复查询也不会有变化，那么整个过程中，多次的请求数据库操作会显得有些多余。
不妨可以将这些空值（没有查询结果的数据）对应的key存储在缓存中，那么第二次查找的时候就不需要再次请求到database那么麻烦，只需要通过内存查询即可。这样的做法能够大大减少对于database的访问压力。
2.布隆过滤器
通常对于database里面的数据的key值可以预先存储在布隆过滤器里面去，然后先在布隆过滤器里面进行过滤，如果发现布隆过滤器中没有的话，就再去redis里面进行查询，如果redis中也没有数据的话，再去database查询。这样可以避免不存在的数据信息也去往存储库中进行查询情况。
什么是缓存雪崩？
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。
如何避免缓存雪崩问题？
1.使用加锁队列来应付这种问题。当有多个请求涌入的时候，当缓存失效的时候加入一把分布式锁，只允许抢锁成功的请求去库里面读取数据然后将其存入缓存中，再释放锁，让后续的读请求从缓存中取数据。但是这种做法有一定的弊端，过多的读请求线程堵塞，将机器内存占满，依然没有能够从根本上解决问题。
2.在并发场景发生前，先手动触发请求，将缓存都存储起来，以减少后期请求对database的第一次查询的压力。数据过期时间设置尽量分散开来，不要让数据出现同一时间段出现缓存过期的情况。
3.从缓存可用性的角度来思考，避免缓存出现单点故障的问题，可以结合使用 主从+哨兵的模式来搭建缓存架构，但是这种模式搭建的缓存架构有个弊端，就是无法进行缓存分片，存储缓存的数据量有限制，因此可以升级为Redis Cluster架构来进行优化处理。（需要结合企业实际的经济实力，毕竟Redis Cluster的搭建需要更多的机器）
4.Ehcache本地缓存 + Hystrix限流&降级,避免MySQL被打死。
使用 Ehcache本地缓存的目的也是考虑在 Redis Cluster 完全不可用的时候，Ehcache本地缓存还能够支撑一阵。
使用 Hystrix进行限流 & 降级 ，比如一秒来了5000个请求，我们可以设置假设只能有一秒 2000个请求能通过这个组件，那么其他剩余的 3000 请求就会走限流逻辑。
然后去调用我们自己开发的降级组件（降级），比如设置的一些默认值呀之类的。以此来保护最后的 MySQL 不会被大量的请求给打死。
㈦ 如何处理大量数据高并发大流量并发操作方案
大数据并发处理解决方案：
1、HTML静态化
效率最高、消耗最小的就是纯静态化的html页面，所以尽可能使网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，无法全部手动去挨个实现，于是出现了常见的信息发布系统CMS，像常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
2、图片服务器分离
对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadMole，保证更高的系统消耗和执行效率。 这一实现起来是比较容易的一现，如果服务器集群操作起来更方便，如果是独立的服务器，新手可能出现上传图片只能在服务器本地的情况下，可以在令一台服务器设置的IIS采用网络路径来实现图片服务器，即不用改变程序，又能提高性能，但对于服务器本身的IO处理性能是没有任何的改变。
3、数据库集群和库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是需要使用数据库集群或者库表散列。
4、缓存
缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。
5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和ENet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。 负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择。
硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。
㈧ 如何解决高并发问题
使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器，(对架构分层+负载均衡+集群)这几个解决思路在一定程度上意味着更大的投入。
1、高并发：在同一个时间点，有大量的客户来访问我们的网站，如果访问量过大，就可能造成网站瘫痪。
2、高流量：当网站大后，有大量的图片，视频，这样就会对流量要求高，需要更多更大的带宽。
3、大存储：可能对数据保存和查询出现问题。
解决方案：
1、提高硬件能力、增加系统服务器。（当服务器增加到某个程度的时候系统所能提供的并发访问量几乎不变，所以不能根本解决问题）
2、本地缓存：本地可以使用JDK自带的Map、Guava Cache.分布式缓存：Redis、Memcache.本地缓存不适用于提高系统并发量，一般是用处用在程序中。
Spiring把已经初始过的变量放在一个Map中，下次再要使用这个变量的时候，先判断Map中有没有，这也就是系统中常见的单例模式的实现。