并发量和tps的关系-并发量和tps的区别

1. 处理电商高并发有什么要求？一般有哪些处理方式？
2. 并发数的计算公式？
3. 系统pv怎么算？
4. Kafka，Mq和Redis作为消息队列使用时的差异有哪些？

处理电商高并发有什么要求？一般有哪些处理方式？

1，HTML静态化 ，将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素。通过CDN来抗峰值。

4.如果请求过多，判定web服务器的压力过大，增加前端的web服务器，做负载均衡

5.图片服务器分离

1：系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。

2：缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发啊。没问题的。所以你可以考的虑考虑你的项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。

3：MQ(消息队列)，必须得用MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那你咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的。

4：分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。

5：读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

6：solrCloud:SolrCloud(solr 云)是Solr提供的分布式搜索方案，可以解决海量数据的 分布式全文检索，因为搭建了集群，因此具备高可用的特性，同时对数据进行主从备份，避免了单点故障问题。可以做到数据的快速恢复。并且可以动态的添加新的节点，再对数据进行平衡,可以做到负载均衡。

我的第一家公司就是电商公司，后面工作基本都是高并发服务开发，下面说下自己对于高并发的拙见。

先来认识下并发的关键术语:

并发量:就是说指定时间段内的访问量，一般用tps(每秒事务数)，QPS(每秒查询数)，响应时间等指标进行表示！

何为高并发？短时间内有大量的请求访问服务器，即TPS或者QPS很高！

高并发对服务器有着极高的要求，而这些要求主要集中在应用服务器和数据库服务器上，所以一般高并发的解决通常是提高应用服务器和数据库的处理能力！

针对应用服务器:

限流:比如说以前玩dota的时候，遇到游戏平台限流，登录了也玩不了！一般限流通过某种算法(计数器，漏桶等)选择性的让一部分请求到达后台，进行处理！

消峰:通常在电商的秒杀系统，活动等场景下，通常会在短时间内出现大量的流量，从正态分布图来看就是一个尖峰，如何让访问变得平缓呢？通常将请求放请求队列，让应用服务主动拉取，进行请求执行！

提高应用服务器能力:

①，连接能力:抛弃传统的多线程(多进程)处理连接的方式，使用基于netty的IO多路复用的架构搭建服务器，提高连接能力，可使用nginx搭建应用服务集群实现负载均衡的同时，保证更多连接。

②，异步处理:避免同步处理引起的阻塞，使用异步调用能提升CPU使用率，避免***浪费。

③，前后端分离:将前后端的代码进行分离，避免彼此之间的影响，前端使用node.js，后端使用微服务架构，提升整体架构的处理能力。

④，集群或者微服务:使用nginx加几台应用服务器组成集群，或者业务解耦搭建微服务架构，避免单点宕机的危害！

⑤，缓存:使用redis，memcache等分布式缓存，存储临时数据，定义表数据，配置等任何可以缓存的东西，借助内存型缓存的快速特性得到更快的处理能力。

⑥，服务间通信:

接口调用:比如springcloud加eureka实现的服务，在eureka服务端实现服务列表的维护，接口的注册和暴露，然后各个服务根据获取的服务列表进行服务调用，可以使用feign实现客户端的负载均衡，保证服务均衡调用。

消息中间件:使用kafka，ons，redis等消息中间件实现服务之间的消息传递，实现异步处理的同时，保证数据不丢失！

⑦，代码优化:避免循环创建对象，线程等，减少使用加锁操作，避免死锁等可能出现的bug，减少对数据库的频繁访问。

针对数据库:

1，提升单个数据库服务的能力，优化数据库服务器性能，连接池优化，经常查看数据库状态(show status;)

2，集群:搭建主从***，读写分离，双主互备，分库分表根据业务量选择不同的集群方式，提供更加优异的性能。

3，利用数据库中间件:使用c***实现数据同步到专门的查询库，或者缓存，使用mycat等组件实现分库分表！

分布式服务系统通常的瓶颈都在数据库上，所以数据库的搭建尤为重要。

同时，在高并发的系统中，还需要注意保持接口的幂等性，数据一致性(通常使用分布式事务，参见我别的回答)！高并发系统瓶颈问题往往在测试过程中很难覆盖，而在生产过程中爆发，所以是作为系统设计的一个难点通常是面试的必问点，上面涉及到的技术，由于篇幅原因，只是涉及到理论实现，实际更多的技术分享，敬请关注。。。

并发数的计算公式？

并发数（Concurrents）可以用下式来计算：并发数 = 测试时间 / 平均响应时间 。

或者，也可以用下式计算：并发数 = 测试时间*TPS / 成功率。

系统pv怎么算？

PV=page view

TPS=transactions per second

QPS=queries per second

RPS=requests per second

RPS=并发数/平均响应时间

Kafka，Mq和Redis作为消息队列使用时的差异有哪些？

分别来说一下：

kafka目前主要作为大数据的流式处理的队列组件，作为大数据的组件，必然是可以处理海量的数据，并且必须具备高可用的特性，是一种分布式的消息队列，保存的数据既有内存中，也有硬盘中，硬盘中的数据默认保留7天。

redis作为目前大热的内存nosql，是一种分布式的内存k-v型数据库，也可以作为消息队列使用，是使用了redis的列表类型，并非专门的消息队列，相比于kafka而言，无法处理海量的数据，但是读取速度由于是内存读取，速度相对较快。

mq作为传统的消息队列，主要应用于传统项目，相对于前二者而言不具备分布式高可用特性。

可按需求来使用。

KAFKA

本人所在的公司使用kafa作为ETL数据通道，通过kafka配套的connect和schemaRegisty来方便快速实现异构数据源的相互转换和存储，通过connect插件生产和消费数据，通过schemaRegisty转换异构数据（可以在几乎所有你知道的数据源之间相互转换），并且数据可以重复被消费（可以通过配置指定数据存储时长）。kafka的开发团队围绕着kafka开发了一整套自成体系的生态圈（confluent platform）。

优点：

1. 可扩展。Kafka集群可以透明的扩展，增加新的服务器进集群。
2. 高性能。Kafka性能远超过传统的ActiveMQ、RabbitMQ等，Kafka支持Batch操作。
3. 容错性。Kafka每个Partition数据会***到几台服务器，当某个Broker失效时，Zookeeper将通知生产者和消费者从而使用其他的Broker。

缺点：

1. 重复消息。Kafka保证每条消息至少送达一次，虽然几率很小，但一条消息可能被送达多次。
2. 消息乱序。Kafka某一个固定的Partition内部的消息是保证有序的，如果一个Topic有多个Partition，partition之间的消息送达不保证有序。
3. 复杂性。Kafka需要Zookeeper的支持，Topic一般需要人工创建，部署和维护比一般MQ成本更高。

MQ

消息队列中间件还有很多种,列举几个:

RocketMq，是阿里在充分reviewkafka代码后，开发的metaQ。在不断更新，修补以后，阿里把metaQ3.0更名为rocket，并且rocket是j***a写的易于维护。

RabbitMQ,支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以***用内存或者硬盘。

REDIS

[免责声明]本文来源于网络，不代表本站立场，如转载内容涉及版权等问题，请联系邮箱:83115484@qq.com，我们会予以删除相关文章，保证您的权利。转载请注明出处：http://www.pj1663.com/post/1659.html