高并发的几种处理方法？

异步编程就是使用future模式（又称promise）或者回调机制来实现（Non-blocking on waiting）。如果使用回调或事件来实现（容易callback hell），不仅编写这样的代码不直观，很快就容易把代码搞得一团糟。

不过在.NET 4.5 及以上框架中引入的async/await关键字（在.NET 4.0中通过添加Microsoft.Bcl.Async包也可以使用），让编写异步代码变得容易和优雅。通过使用async/await关键字，可以像写同步代码那样编写异步代码，所有的回调和事件处理都交给编译器和运行时帮你处理了，简单好用。

使用异步编程有两个好处：不阻塞主线程（比如UI线程），提高服务端应用的吞吐量。所以微软推荐ASP.NET中默认使用异步来处理请求。

例如：我用异步做微信模板消息推送。

-》硬件

集群：多台服务器分流 ，静态资源集群和动态资源集群，需要考虑session同步问题

CDN:使用CDN存放静态资源

反向代理：用别的服务器代理处理

-》软件

动静分离：静态资源和动态资源分离，把静态资源放到单独的服务器

页面缓存：经常访问的页面可以做成静态页面放到缓存里

缩短请求路径：缩短请求服务的路径，便于解析

批量读取：多个请求合并到一起请求，减少数据库访问次数

延迟修改：把多次修改请求先放到缓存中，然后同步到库

1.Where语句中不要出现Null、or、!=、<>、in、not in否则会避开索引进行全表扫描

2.尽量避免在索引过的字符数据中，使用非打头字母搜索，否则会避开索引进行全表扫如：SELECT * FROM T1 WHERE NAME LIKE ‘%L%’ SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’

3.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描如：select id from t where num=@num可以改为强制查询使用索引：select id from t with(index(索引名)) where num=@num

4.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

SELECT * FROM T1 WHERE F1/2=100

应改为:

SELECT * FROM T1 WHERE F1=100*2SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’应改为: 

SELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’SELECT member_number, first_name, last_name FROM members WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21

应改为:

SELECT member_number, first_name, last_name FROM members WHERE dateofbirth < DATEADD(yy,-21,GETDATE())即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

5.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where substring(name,1,3)='abc'--name以abc开头的idselect id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id

应改为:

select id from t where name like 'abc%'select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'6.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无确使用索引。

7.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

很多时候用 exists是一个好的选择：

elect num from a where num in(select num from b)用下面的语句替换：

select num from a where exists(select 1 from b where num=a.num)SELECT SUM(T1.C1)FROM T1 WHERE( (SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0) SELECT SUM(T1.C1) FROM T1WHERE EXISTS( SELECT * FROM T2 WHERE T2.C2=T1.C2)

两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

如果你想校验表里是否存在某条纪录，不要用count(*)那样效率很低，而且浪费服务器资源。可以用EXISTS代替。如：

IF (SELECT COUNT(*) FROM table_name WHERE column_name = 'xxx')可以写成： 

IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx')经常需要写一个T_SQL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中没有的记录，如： 

SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用别名a代替 WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key) SELECT a.hdr_key FROM hdr_tbl a LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL SELECT hdr_key FROM hdr_tbl WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)

三种写法都可以得到同样正确的结果，但是效率依次降低。

1.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。

2.避免频繁创建和删除临时表，以减少系统表资源的消耗。

3.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

4.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。

5.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

6.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

7.尽量避免大事务操作，提高系统并发能力。

8.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

9.避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如: SELECT name FROM employee WHERE salary > 60000 在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。

10.充分利用连接条件，在某种情况下，两个表之间可能不只一个的连接条件，这时在 WHERE 子句中将连接条件完整的写上，有可能大大提高查询速度。 例：

SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO第二句将比第一句执行快得多。

1.使用视图加速查询 把表的一个子集进行排序并创建视图，有时能加速查询。它有助于避免多重排序 操作，而且在其他方面还能简化优化器的工作

2.能用DISTINCT的就不用GROUP BY

3.能用UNION ALL就不要用UNION

4.尽量不要用SELECT INTO语句。 SELECT INOT 语句会导致表锁定，阻止其他用户访问该表。

5.尽量避免使用游标，因为游标的效率较差

PMP备考学习资料需要的同学私信找我，内含pmp备考资料 EPC工程管理资料 各种模板表格与5GB质量管理资料等等！

Kafka如何实现每秒上百万的超高并发写入？

这篇文章来聊一下 Kafka 的一些架构设计原理，这也是互联网公司面试时非常高频的技术考点。

Kafka 是高吞吐低延迟的高并发、高性能的消息中间件，在大数据领域有极为广泛的运用。配置良好的 Kafka 集群甚至可以做到每秒几十万、上百万的超高并发写入。

那么 Kafka 到底是如何做到这么高的吞吐量和性能的呢?这篇文章我们来详细说一下。

页缓存技术 + 磁盘顺序写

首先 Kafka 每次接收到数据都会往磁盘上去写，如下图所示：

那么在这里我们不禁有一个疑问了，如果把数据基于磁盘来存储，频繁的往磁盘文件里写数据，这个性能会不会很差?大家肯定都觉得磁盘写性能是极差的。

没错，要是真的跟上面那个图那么简单的话，那确实这个性能是比较差的。

但是实际上 Kafka 在这里有极为优秀和出色的设计，就是为了保证数据写入性能，首先 Kafka 是基于操作系统的页缓存来实现文件写入的。

操作系统本身有一层缓存，叫做 Page Cache，是在内存里的缓存，我们也可以称之为 OS Cache，意思就是操作系统自己管理的缓存。

你在写入磁盘文件的时候，可以直接写入这个 OS Cache 里，也就是仅仅写入内存中，接下来由操作系统自己决定什么时候把 OS Cache 里的数据真的刷入磁盘文件中。

仅仅这一个步骤，就可以将磁盘文件写性能提升很多了，因为其实这里相当于是在写内存，不是在写磁盘，大家看下图：

接着另外一个就是 kafka 写数据的时候，非常关键的一点，它是以磁盘顺序写的方式来写的。

也就是说，仅仅将数据追加到文件的末尾，不是在文件的随机位置来修改数据。

普通的机械磁盘如果你要是随机写的话，确实性能极差，也就是随便找到文件的某个位置来写数据。

但是如果你是追加文件末尾按照顺序的方式来写数据的话，那么这种磁盘顺序写的性能基本上可以跟写内存的性能本身也是差不多的。

所以大家就知道了，上面那个图里，Kafka 在写数据的时候，一方面基于 OS 层面的 Page Cache 来写数据，所以性能很高，本质就是在写内存罢了。

另外一个，它是采用磁盘顺序写的方式，所以即使数据刷入磁盘的时候，性能也是极高的，也跟写内存是差不多的。

基于上面两点，Kafka 就实现了写入数据的超高性能。那么大家想想，假如说 Kafka 写入一条数据要耗费 1 毫秒的时间，那么是不是每秒就是可以写入 1000 条数据?

但是假如 Kafka 的性能极高，写入一条数据仅仅耗费 0.01 毫秒呢?那么每秒是不是就可以写入 10 万条数据?

所以要保证每秒写入几万甚至几十万条数据的核心点，就是尽最大可能提升每条数据写入的性能，这样就可以在单位时间内写入更多的数据量，提升吞吐量。

零拷贝技术

说完了写入这块，再来谈谈消费这块。

大家应该都知道，从 Kafka 里我们经常要消费数据，那么消费的时候实际上就是要从 Kafka 的磁盘文件里读取某条数据然后发送给下游的消费者，如下图所示：

那么这里如果频繁的从磁盘读数据然后发给消费者，性能瓶颈在哪里呢?

假设要是 Kafka 什么优化都不做，就是很简单的从磁盘读数据发送给下游的消费者，那么大概过程如下所示：

先看看要读的数据在不在 OS Cache 里，如果不在的话就从磁盘文件里读取数据后放入 OS Cache。

接着从操作系统的 OS Cache 里拷贝数据到应用程序进程的缓存里，再从应用程序进程的缓存里拷贝数据到操作系统层面的 Socket 缓存里。

最后从 Socket 缓存里提取数据后发送到网卡，最后发送出去给下游消费。

整个过程，如下图所示：

大家看上图，很明显可以看到有两次没必要的拷贝吧!一次是从操作系统的 Cache 里拷贝到应用进程的缓存里，接着又从应用程序缓存里拷贝回操作系统的 Socket 缓存里。

而且为了进行这两次拷贝，中间还发生了好几次上下文切换，一会儿是应用程序在执行，一会儿上下文切换到操作系统来执行。

所以这种方式来读取数据是比较消耗性能的。Kafka 为了解决这个问题，在读数据的时候是引入零拷贝技术。

也就是说，直接让操作系统的 Cache 中的数据发送到网卡后传输给下游的消费者，中间跳过了两次拷贝数据的步骤，Socket 缓存中仅仅会拷贝一个描述符过去，不会拷贝数据到 Socket 缓存。

大家看下图，体会一下这个精妙的过程：

通过零拷贝技术，就不需要把 OS Cache 里的数据拷贝到应用缓存，再从应用缓存拷贝到 Socket 缓存了，两次拷贝都省略了，所以叫做零拷贝。

对 Socket 缓存仅仅就是拷贝数据的描述符过去，然后数据就直接从 OS Cache 中发送到网卡上去了，这个过程大大的提升了数据消费时读取文件数据的性能。

而且大家会注意到，在从磁盘读数据的时候，会先看看 OS Cache 内存中是否有，如果有的话，其实读数据都是直接读内存的。

如果 Kafka 集群经过良好的调优，大家会发现大量的数据都是直接写入 OS Cache 中，然后读数据的时候也是从 OS Cache 中读。

相当于是 Kafka 完全基于内存提供数据的写和读了，所以这个整体性能会极其的高。

说个题外话，下回有机会给大家说一下 Elasticsearch 的架构原理，其实 ES 底层也是大量基于 OS Cache 实现了海量数据的高性能检索的，跟 Kafka 原理类似。

总结

通过这篇文章对 Kafka 底层的页缓存技术的使用，磁盘顺序写的思路，以及零拷贝技术的运用，大家应该就明白 Kafka 每台机器在底层对数据进行写和读的时候采取的是什么样的思路，为什么它的性能可以那么高，做到每秒几十万的吞吐量。