快乐分享，Java干货及时送达👇

大家知道，Notepad++作者经常大量发表错误言论，且拒不认错，引发了广大程序员的强烈反对，很多人因此而弃用这款软件，纷纷改用其它文本编辑器。而今天推荐的这款开源文本编辑器呢，就是国内大佬写的类似Notepad++的文本编辑器—Notepad–！

这位大佬也是性情中人，看不惯那小人嘴脸，发誓要自己开发一款超越Notepad++的国内开源文本编辑器，埋头苦干一段时间，终于在Gitee上推出了他的作品。至于名称取为Notepad–，大佬说：

❝

鉴于Notepad++作者的错误言论，Notepad–的意义在于：减少一点错误言论，减少一点自以为是。严正声明，台湾是中国的一部分！

❞

下面向各位小伙伴简单介绍一下：

项目特点

作为一个来自中国的、支持windows/linux/mac、绿色免费的、开源的文本编辑器，目标是要替换notepad++。该项目是采用了C++进行开发，针对NotePad++中比较受欢迎的诸多功能与特点进行了分析和吸收，逐渐在项目中加以实现。

功能特点

• 支持国产uos和苹果os系统

• 文件夹对比同步

• 文件对比同步

• 二进制文件对比

• 文件编码批量转换

功能界面

支持国产uos和苹果os系统

文件夹对比同步

支持文件对比及同步，编辑修改，撤销修改等

支持文本单词高亮

支持文件夹中批量查找

支持文件编码批量修改

支持皮肤切换

支持二进制文件显示和跳转查看

以上截图都是截取了一部分内容，如果大家有兴趣了解或者试用更详细的内容，可以去项目地址：

❝

https://gitee.com/cxasm/notepad–/tree/master

❞

最后

Notepad–开源项目也提供全部源代码，方便大家下载研习。大家不仅可以通过使用Notepad–来体验和提升工作效率，尝试替换掉Notepad++，还可以通过对源代码学习和了解如何编写一个主流MDI文本编辑器，也许将来的最好最实用的文本编辑器就是出自你们手中哦！

• 一、Apache三种工作模式
• 1、prefork的工作原理
• 2、worker的工作原理
• 3、event 基于事件机制的特性
• 二、如何提高Web服务器的并发连接处理能力
• 三、Nginx优异之处
• 四、Nginx 工作原理
• 五、Nginx 的诞生主要解决C10K问题
• 1、select模型：（apache使用，由于受模块等限制，用的不多）；
• 2、poll：poll是unix沿用select自己重新实现了一遍，唯一解决的问题是poll 没有最大文件描述符数量的限制；
• 3、epoll模型：（Nginx使用）

Nginx才短短几年，就拿下了Web服务器大壁江山，众所周知，Nginx在处理大并发静态请求方面，效率明显高于Httpd，甚至能轻松解决C10K问题。

在高并发连接的情况下，Nginx是Apache服务器不错的替代品。Nginx同时也可以作为7层负载均衡服务器来使用。根据我的测试结果，Nginx + PHP(FastCGI) 可以承受3万以上的并发连接数，相当于同等环境下Apache的10倍。

一般来说，4GB内存的服务器+Apache（prefork模式）一般只能处理3000个并发连接，因为它们将占用3GB以上的内存，还得为系统预留1GB的内存。我曾经就有两台Apache服务器，因为在配置文件中设置的MaxClients为4000，当Apache并发连接数达到3800时，导致服务器内存和Swap空间用满而崩溃。

而这台 Nginx + PHP(FastCGI) 服务器在3万并发连接下，开启的10个Nginx进程消耗150M内存（15M*10=150M），开启的64个php-cgi进程消耗1280M内存（20M*64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。如果服务器内存较小，完全可以只开启25个php-cgi进程，这样php-cgi消耗的总内存数才500M。

在3万并发连接下，访问Nginx+ PHP(FastCGI) 服务器的PHP程序，仍然速度飞快。

为什么Nginx在处理高并发方面要优于httpd，我们先从两种web服务器的工作原理以及工作模式说起。

一、Apache三种工作模式

我们都知道Apache有三种工作模块，分别为：prefork、worker、event。

• prefork： 多进程，每个请求用一个进程响应，这个过程会用到select机制来通知。
• worker： 多线程，一个进程可以生成多个线程，每个线程响应一个请求，但通知机制还是select不过可以接受更多的请求。
• event： 基于异步I/O模型，一个进程或线程，每个进程或线程响应多个用户请求，它是基于事件驱动（也就是epoll机制）实现的。

1、prefork的工作原理

如果不用“–with-mpm”显式指定某种MPM，prefork就是Unix平台上缺省的MPM。它所采用的预派生子进程方式也是 Apache1.3中采用的模式。prefork本身并没有使用到线程，2.0版使用它是为了与1.3版保持兼容性；另一方面，prefork用单独的子进程来处理不同的请求，进程之间是彼此独立的,这也使其成为最稳定的MPM之一。

2、worker的工作原理

相对于prefork，worker是2.0版中全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理，所以可以处理相对海量的请求，而系统资源的开销要小于基于进程的服务器。但是，worker也使用了多进程,每个进程又生成多个线程，以获得基于进程服务器的稳定性，这种MPM的工作方 式将是Apache2.0的发展趋势。

3、event 基于事件机制的特性

一个进程响应多个用户请求，利用callback机制，让套接字复用，请求过来后进程并不处理请求，而是直接交由其他机制来处理，通过epoll机制来通知请求是否完成；在这个过程中，进程本身一直处于空闲状态，可以一直接收用户请求。可以实现一个进程程响应多个用户请求。支持持海量并发连接数，消耗更少的资源。

二、如何提高Web服务器的并发连接处理能力

有几个基本条件：

1、基于线程，即一个进程生成多个线程，每个线程响应用户的每个请求。

2、基于事件的模型，一个进程处理多个请求，并且通过epoll机制来通知用户请求完成。

3、基于磁盘的AIO（异步I/O）

4、支持mmap内存映射，mmap传统的web服务器，进行页面输入时，都是将磁盘的页面先输入到内核缓存中，再由内核缓存中复制一份到web服务器上，mmap机制就是让内核缓存与磁盘进行映射，web服务器，直接复制页面内容即可。不需要先把磁盘的上的页面先输入到内核缓存去。

刚好，Nginx 支持以上所有特性。所以Nginx官网上说，Nginx支持50000并发，是有依据的。

三、Nginx优异之处

传统上基于进程或线程模型架构的Web服务通过每进程或每线程处理并发连接请求，这势必会在网络和I/O操作时产生阻塞，其另一个必然结果则是对内存或CPU的利用率低下。

生成一个新的进程/线程需要事先备好其运行时环境，这包括为其分配堆内存和栈内存，以及为其创建新的执行上下文等。这些操作都需要占用CPU，而且过多的进程/线程还会带来线程抖动或频繁的上下文切换，系统性能也会由此进一步下降。

另一种高性能web服务器/Web服务器反向代理：Nginx，Nginx的主要着眼点就是其高性能以及对物理计算资源的高密度利用，因此其采用了不同的架构模型。受启发于多种操作系统设计中基于“事件”的高级处理机制，Nginx采用了模块化、事件驱动、异步、单线程及非阻塞的架构，并大量采用了多路复用及事件通知机制。

在Nginx中，连接请求由为数不多的几个仅包含一个线程的进程Worker以高效的回环(run-loop)机制进行处理，而每个Worker可以并行处理数千个的并发连接及请求。

四、Nginx 工作原理

Nginx会按需同时运行多个进程：一个主进程(master)和几个工作进程(worker)，配置了缓存时还会有缓存加载器进程(cache loader)和缓存管理器进程(cache manager)等。所有进程均是仅含有一个线程，并主要通过“共享内存”的机制实现进程间通信。主进程以root用户身份运行，而worker、cache loader和cache manager均应以非特权用户身份运行。

在高连接并发的情况下，Nginx是Apache服务器不错的替代品。

Nginx 安装非常的简单 , 配置文件非常简洁（还能够支持perl语法）,Bugs 非常少的服务器: Nginx 启动特别容易, 并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动. 你还能够 不间断服务的情况下进行软件版本的升级 。

五、Nginx 的诞生主要解决C10K问题

最后我们从各自使用的多路复用IO模型来分析：

1、select模型：（apache使用，由于受模块等限制，用的不多）；

单个进程能够 监视的文件描述符的数量存在最大限制；

select()所维护的 存储大量文件描述符的数据结构 ，随着文件描述符数量的增长，其在用户态和内核的地址空间的复制所引发的开销也会线性增长；

由于网络响应时间的延迟使得大量TCP连接处于非活跃状态，但调用select()还是会对 所有的socket进行一次线性扫描 ，会造成一定的开销；

2、poll：poll是unix沿用select自己重新实现了一遍，唯一解决的问题是poll 没有最大文件描述符数量的限制；

3、epoll模型：（Nginx使用）

epoll带来了两个优势，大幅度提升了性能：

（1）基于事件的就绪通知方式 ，select/poll方式，进程只有在调用一定的方法后，内核才会对所有监视的文件描述符进行扫描，而epoll事件通过epoll_ctl()注册一个文件描述符，一旦某个文件描述符就绪时，内核会采用类似call back的回调机制，迅速激活这个文件描述符，epoll_wait()便会得到通知

（2）调用一次epoll_wait()获得就绪文件描述符时，返回的并不是实际的描述符，而是一个代表就绪描述符数量的值，拿到这些值去epoll指定的一个数组中依次取得相应数量的文件描述符即可，这里使用内存映射（mmap）技术， 避免了复制大量文件描述符带来的开销

（3）当然epoll也有一定的局限性， epoll只有Linux2.6才有实现 ，而其他平台都没有，这和apache这种优秀的跨平台服务器，显然是有些背道而驰了。

（4）简单来说epoll是select的升级版，单进程管理的文件描述符没有最大限制。但epoll只有linux平台可使用。作为跨平台的Apache没有使用

• 12306抢票,极限并发带来的思考?
• 1. 大型高并发系统架构
• 2.秒杀抢购系统选型
• 3. 扣库存的艺术
• 4. 代码演示
• 5.总结回顾

每到节假日期间,一二线城市返乡、外出游玩的人们几乎都面临着一个问题：抢火车票!虽然现在大多数情况下都能订到票,但是放票瞬间即无票的场景，相信大家都深有体会。尤其是春节期间，大家不仅使用12306，还会考虑“智行”和其他的抢票软件,全国上下几亿人在这段时间都在抢票。

“12306服务”承受着这个世界上任何秒杀系统都无法超越的QPS,上百万的并发再正常不过了！笔者专门研究了一下“12306”的服务端架构,学习到了其系统设计上很多亮点，在这里和大家分享一下并模拟一个例子：如何在100万人同时抢1万张火车票时，系统提供正常、稳定的服务。

github代码地址：https://github.com/GuoZhaoran/spikeSystem

1.1 负载均衡简介

上图中描述了用户请求到服务器经历了三层的负载均衡，下边分别简单介绍一下这三种负载均衡：

1.2 Nginx加权轮询的演示

Nginx实现负载均衡通过upstream模块实现，其中加权轮询的配置是可以给相关的服务加上一个权重值，配置的时候可能根据服务器的性能、负载能力设置相应的负载。下面是一个加权轮询负载的配置，我将在本地的监听3001-3004端口,分别配置1，2，3，4的权重:

#配置负载均衡
    upstream load_rule {
       server 127.0.0.1:3001 weight=1;
       server 127.0.0.1:3002 weight=2;
       server 127.0.0.1:3003 weight=3;
       server 127.0.0.1:3004 weight=4;
    }
    ...
    server {
    listen       80;
    server_name  load_balance.com www.load_balance.com;
    location / {
       proxy_pass http://load_rule;
    }
}

我在本地/etc/hosts目录下配置了 www.load_balance.com的虚拟域名地址，接下来使用Go语言开启四个http端口监听服务，下面是监听在3001端口的Go程序,其他几个只需要修改端口即可：

package main

import (
 "net/http"
 "os"
 "strings"
)

func main() {
 http.HandleFunc("/buy/ticket", handleReq)
 http.ListenAndServe(":3001", nil)
}

//处理请求函数,根据请求将响应结果信息写入日志
func handleReq(w http.ResponseWriter, r *http.Request) {
 failedMsg :=  "handle in port:"
 writeLog(failedMsg, "./stat.log")
}

//写入日志
func writeLog(msg string, logPath string) {
 fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)
 defer fd.Close()
 content := strings.Join([]string{msg, "rn"}, "3001")
 buf := []byte(content)
 fd.Write(buf)
}

我将请求的端口日志信息写到了./stat.log文件当中，然后使用ab压测工具做压测:

ab -n 1000 -c 100 http://www.load_balance.com/buy/ticket

统计日志中的结果，3001-3004端口分别得到了100、200、300、400的请求量，这和我在nginx中配置的权重占比很好的吻合在了一起，并且负载后的流量非常的均匀、随机。

从上面的介绍我们知道用户秒杀流量通过层层的负载均衡，均匀到了不同的服务器上，即使如此，集群中的单机所承受的QPS也是非常高的。如何将单机性能优化到极致呢？要解决这个问题，我们就要想明白一件事：通常订票系统要处理生成订单、减扣库存、用户支付这三个基本的阶段，我们系统要做的事情是要保证火车票订单不超卖、不少卖 ，每张售卖的车票都必须支付才有效，还要保证系统承受极高的并发。这三个阶段的先后顺序改怎么分配才更加合理呢?我们来分析一下：

2.1 下单减库存

当用户并发请求到达服务端时，首先创建订单，然后扣除库存，等待用户支付。这种顺序是我们一般人首先会想到的解决方案，这种情况下也能保证订单不会超卖，因为创建订单之后就会减库存，这是一个原子操作。但是这样也会产生一些问题，第一就是在极限并发情况下，任何一个内存操作的细节都至关影响性能，尤其像创建订单这种逻辑，一般都需要存储到磁盘数据库的，对数据库的压力是可想而知的；第二是如果用户存在恶意下单的情况，只下单不支付这样库存就会变少，会少卖很多订单，虽然服务端可以限制IP和用户的购买订单数量，这也不算是一个好方法。

2.2 支付减库存

如果等待用户支付了订单在减库存，第一感觉就是不会少卖。但是这是并发架构的大忌，因为在极限并发情况下，用户可能会创建很多订单，当库存减为零的时候很多用户发现抢到的订单支付不了了，这也就是所谓的“超卖”。也不能避免并发操作数据库磁盘IO

2.3 预扣库存

从上边两种方案的考虑，我们可以得出结论：只要创建订单，就要频繁操作数据库IO。那么有没有一种不需要直接操作数据库IO的方案呢，这就是预扣库存。先扣除了库存，保证不超卖，然后异步生成用户订单，这样响应给用户的速度就会快很多；那么怎么保证不少卖呢？用户拿到了订单，不支付怎么办？

我们都知道现在订单都有有效期，比如说用户五分钟内不支付，订单就失效了，订单一旦失效，就会加入新的库存，这也是现在很多网上零售企业保证商品不少卖采用的方案。订单的生成是异步的,一般都会放到MQ、kafka这样的即时消费队列中处理,订单量比较少的情况下，生成订单非常快，用户几乎不用排队。

在单机低并发情况下，我们实现扣库存通常是这样的:

为了保证扣库存和生成订单的原子性，需要采用事务处理，然后取库存判断、减库存，最后提交事务，整个流程有很多IO，对数据库的操作又是阻塞的。这种方式根本不适合高并发的秒杀系统。

接下来我们对单机扣库存的方案做优化：本地扣库存 。我们把一定的库存量分配到本地机器，直接在内存中减库存，然后按照之前的逻辑异步创建订单。改进过之后的单机系统是这样的:

这样就避免了对数据库频繁的IO操作，只在内存中做运算，极大的提高了单机抗并发的能力。但是百万的用户请求量单机是无论如何也抗不住的，虽然nginx处理网络请求使用epoll模型，c10k的问题在业界早已得到了解决。但是linux系统下，一切资源皆文件，网络请求也是这样，大量的文件描述符会使操作系统瞬间失去响应。

上面我们提到了nginx的加权均衡策略，我们不妨假设将100W的用户请求量平均均衡到100台服务器上，这样单机所承受的并发量就小了很多。然后我们每台机器本地库存100张火车票，100台服务器上的总库存还是1万，这样保证了库存订单不超卖,下面是我们描述的集群架构:

问题接踵而至，在高并发情况下，现在我们还无法保证系统的高可用，假如这100台服务器上有两三台机器因为扛不住并发的流量或者其他的原因宕机了。那么这些服务器上的订单就卖不出去了，这就造成了订单的少卖。

要解决这个问题，我们需要对总订单量做统一的管理，这就是接下来的容错方案。服务器不仅要在本地减库存，另外要远程统一减库存 。有了远程统一减库存的操作，我们就可以根据机器负载情况，为每台机器分配一些多余的“buffer库存”用来防止机器中有机器宕机的情况。我们结合下面架构图具体分析一下:

我们采用Redis存储统一库存，因为Redis的性能非常高，号称单机QPS能抗10W的并发。在本地减库存以后，如果本地有订单，我们再去请求redis远程减库存，本地减库存和远程减库存都成功了，才返回给用户抢票成功的提示,这样也能有效的保证订单不会超卖。

当机器中有机器宕机时，因为每个机器上有预留的buffer余票，所以宕机机器上的余票依然能够在其他机器上得到弥补，保证了不少卖。buffer余票设置多少合适呢，理论上buffer设置的越多，系统容忍宕机的机器数量就越多，但是buffer设置的太大也会对redis造成一定的影响。

虽然redis内存数据库抗并发能力非常高，请求依然会走一次网络IO,其实抢票过程中对redis的请求次数是本地库存和buffer库存的总量，因为当本地库存不足时，系统直接返回用户“已售罄”的信息提示，就不会再走统一扣库存的逻辑，这在一定程度上也避免了巨大的网络请求量把redis压跨，所以buffer值设置多少，需要架构师对系统的负载能力做认真的考量。

4.1 初始化工作

go包中的init函数先于main函数执行，在这个阶段主要做一些准备性工作。我们系统需要做的准备工作有：初始化本地库存、初始化远程redis存储统一库存的hash键值、初始化redis连接池；另外还需要初始化一个大小为1的int类型chan,目的是实现分布式锁的功能，也可以直接使用读写锁或者使用redis等其他的方式避免资源竞争,但使用channel更加高效，这就是go语言的哲学：不要通过共享内存来通信，而要通过通信来共享内存 。redis库使用的是redigo，下面是代码实现:

...
//localSpike包结构体定义
package localSpike

type LocalSpike struct {
 LocalInStock     int64
 LocalSalesVolume int64
}
...
//remoteSpike对hash结构的定义和redis连接池
package remoteSpike
//远程订单存储健值
type RemoteSpikeKeys struct {
 SpikeOrderHashKey string //redis中秒杀订单hash结构key
 TotalInventoryKey string //hash结构中总订单库存key
 QuantityOfOrderKey string //hash结构中已有订单数量key
}

//初始化redis连接池
func NewPool() *redis.Pool {
 return &redis.Pool{
  MaxIdle:   10000,
  MaxActive: 12000, // max number of connections
  Dial: func() (redis.Conn, error) {
   c, err := redis.Dial("tcp", ":6379")
   if err != nil {
    panic(err.Error())
   }
   return c, err
  },
 }
}
...
func init() {
 localSpike = localSpike2.LocalSpike{
  LocalInStock:     150,
  LocalSalesVolume: 0,
 }
 remoteSpike = remoteSpike2.RemoteSpikeKeys{
  SpikeOrderHashKey:  "ticket_hash_key",
  TotalInventoryKey:  "ticket_total_nums",
  QuantityOfOrderKey: "ticket_sold_nums",
 }
 redisPool = remoteSpike2.NewPool()
 done = make(chan int, 1)
 done 1
}

4.2 本地扣库存和统一扣库存

本地扣库存逻辑非常简单，用户请求过来，添加销量，然后对比销量是否大于本地库存，返回bool值:

package localSpike
//本地扣库存,返回bool值
func (spike *LocalSpike) LocalDeductionStock() bool{
 spike.LocalSalesVolume = spike.LocalSalesVolume + 1
 return spike.LocalSalesVolume }

注意这里对共享数据LocalSalesVolume的操作是要使用锁来实现的，但是因为本地扣库存和统一扣库存是一个原子性操作，所以在最上层使用channel来实现，这块后边会讲。统一扣库存操作redis，因为redis是单线程的，而我们要实现从中取数据，写数据并计算一些列步骤，我们要配合lua脚本打包命令，保证操作的原子性:

package remoteSpike
......
const LuaScript = `
        local ticket_key = KEYS[1]
        local ticket_total_key = ARGV[1]
        local ticket_sold_key = ARGV[2]
        local ticket_total_nums = tonumber(redis.call('HGET', ticket_key, ticket_total_key))
        local ticket_sold_nums = tonumber(redis.call('HGET', ticket_key, ticket_sold_key))
  -- 查看是否还有余票,增加订单数量,返回结果值
       if(ticket_total_nums >= ticket_sold_nums) then
            return redis.call('HINCRBY', ticket_key, ticket_sold_key, 1)
        end
        return 0
`
//远端统一扣库存
func (RemoteSpikeKeys *RemoteSpikeKeys) RemoteDeductionStock(conn redis.Conn) bool {
 lua := redis.NewScript(1, LuaScript)
 result, err := redis.Int(lua.Do(conn, RemoteSpikeKeys.SpikeOrderHashKey, RemoteSpikeKeys.TotalInventoryKey, RemoteSpikeKeys.QuantityOfOrderKey))
 if err != nil {
  return false
 }
 return result != 0
}

我们使用hash结构存储总库存和总销量的信息,用户请求过来时，判断总销量是否大于库存，然后返回相关的bool值。在启动服务之前，我们需要初始化redis的初始库存信息:

 hmset ticket_hash_key "ticket_total_nums" 10000 "ticket_sold_nums" 0

4.3 响应用户信息

我们开启一个http服务，监听在一个端口上:

package main
...
func main() {
 http.HandleFunc("/buy/ticket", handleReq)
 http.ListenAndServe(":3005", nil)
}

上面我们做完了所有的初始化工作，接下来handleReq的逻辑非常清晰，判断是否抢票成功，返回给用户信息就可以了。

package main
//处理请求函数,根据请求将响应结果信息写入日志
func handleReq(w http.ResponseWriter, r *http.Request) {
 redisConn := redisPool.Get()
 LogMsg := ""
  //全局读写锁
 if localSpike.LocalDeductionStock() && remoteSpike.RemoteDeductionStock(redisConn) {
  util.RespJson(w, 1,  "抢票成功", nil)
  LogMsg = LogMsg + "result:1,localSales:" + strconv.FormatInt(localSpike.LocalSalesVolume, 10)
 } else {
  util.RespJson(w, -1, "已售罄", nil)
  LogMsg = LogMsg + "result:0,localSales:" + strconv.FormatInt(localSpike.LocalSalesVolume, 10)
 }
 done 1

 //将抢票状态写入到log中
 writeLog(LogMsg, "./stat.log")
}

func writeLog(msg string, logPath string) {
 fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)
 defer fd.Close()
 content := strings.Join([]string{msg, "rn"}, "")
 buf := []byte(content)
 fd.Write(buf)
}

前边提到我们扣库存时要考虑竞态条件，我们这里是使用channel避免并发的读写，保证了请求的高效顺序执行。我们将接口的返回信息写入到了./stat.log文件方便做压测统计。

4.4 单机服务压测

开启服务，我们使用ab压测工具进行测试：

ab -n 10000 -c 100 http://127.0.0.1:3005/buy/ticket

下面是我本地低配mac的压测信息

This is ApacheBench, Version 2.3 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:
Server Hostname:        127.0.0.1
Server Port:            3005

Document Path:          /buy/ticket
Document Length:        29 bytes

Concurrency Level:      100
Time taken for tests:   2.339 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      1370000 bytes
HTML transferred:       290000 bytes
Requests per second:    4275.96 [#/sec] (mean)
Time per request:       23.387 [ms] (mean)
Time per request:       0.234 [ms] (mean, across all concurrent requests)
Transfer rate:          572.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    8  14.7      6     223
Processing:     2   15  17.6     11     232
Waiting:        1   11  13.5      8     225
Total:          7   23  22.8     18     239

Percentage of the requests served within a certain time (ms)
  50%     18
  66%     24
  75%     26
  80%     28
  90%     33
  95%     39
  98%     45
  99%     54
 100%    239 (longest request)

根据指标显示，我单机每秒就能处理4000+的请求，正常服务器都是多核配置，处理1W+的请求根本没有问题。而且查看日志发现整个服务过程中，请求都很正常，流量均匀，redis也很正常：

//stat.log
...
result:1,localSales:145
result:1,localSales:146
result:1,localSales:147
result:1,localSales:148
result:1,localSales:149
result:1,localSales:150
result:0,localSales:151
result:0,localSales:152
result:0,localSales:153
result:0,localSales:154
result:0,localSales:156
...

总体来说，秒杀系统是非常复杂的。我们这里只是简单介绍模拟了一下单机如何优化到高性能，集群如何避免单点故障，保证订单不超卖、不少卖的一些策略，完整的订单系统还有订单进度的查看，每台服务器上都有一个任务，定时的从总库存同步余票和库存信息展示给用户,还有用户在订单有效期内不支付，释放订单，补充到库存等等。

我们实现了高并发抢票的核心逻辑，可以说系统设计的非常的巧妙，巧妙的避开了对DB数据库IO的操作，对Redis网络IO的高并发请求，几乎所有的计算都是在内存中完成的，而且有效的保证了不超卖、不少卖，还能够容忍部分机器的宕机。我觉得其中有两点特别值得学习总结：

快乐分享，Java干货及时送达👇

Agora Flat开源教室是一款高效实用且专业的互动课堂软件，Agora Flat开源教室能够帮助用户快速搭建简约的互动教室，实现网上学习和授课等功能，提高教学效率。

Agora Flat开源教室客户端支持大小课班和一对一的模式，用户可以多情景灵便转换，进行优质课堂教学。

特性

• 实时交互：多功能互动白板，实时音视频（RTC）通讯，即时消息（RTM）聊天
• 登录方式：微信，GitHub
• 房间管理：加入、创建、预定房间，支持周期性房间
• 课堂录制回放：白板信令回放，音视频云录制回放，群聊信令回放
• 多媒体课件云盘
• 屏幕共享

功能

轻松创建丰富多样的在线教室

• 大班课

适用于大型课堂授课，知识传递效率更高。学生可举手发言参与在线互动。

• 小班课

适用于 1 名教师和 2～16 名学生进行在线教学，互动性更及时，趣味性更高，提高教学效率的同时保证质量。

• 一对一

适用于 1 名老师对 1 名学生，沉浸式的个性化课堂教学，学习效果更加明显。

支持自定义主题和 UI

场景插件：无限的组合，无限的可能

安装运行

快速上手

你可以在没有服务端的情况下构建并运行 Flat 客户端。此仓库包含以下项目：

Flat Electron 客户端

https://github.com/netless-io/flat/tree/main/desktop

Flat Web 客户端

https://github.com/netless-io/flat/tree/main/web

安装

如果你还没有安装 pnpm：

npm i -g pnpm

Clone 或者 fork 这个项目，在根目录执行：

pnpm i

构建并运行 Flat Electron 客户端

在仓库根目录运行以下命令：

pnpm start

你可以运行以下命令将项目打包成可执行文件：

• 项目根目录执行 pnpm ship 将根据当前系统打包。
• 或者项目根目录执行 pnpm ship:mac 或 pnpm ship:win 可针对指定的系统打包。

如果你因为网络问题导致无法下载 electron，可在项目目录新建: .npmrc 文件，并写入 ELECTRON_MIRROR=" https://npmmirror.com/mirrors/electron/" 内容。重新执行 pnpm i 即可。

构建并运行 Flat Web 客户端

在仓库根目录运行以下任意一个命令：

pnpm start:web

cd ./web/flat-web/ && pnpm start

在 Flat 中 UI 逻辑与业务逻辑分开开发。可以通过 Storybook 快速查看与开发部分 UI。在项目根目录执行 pnpm storybook 在本地运行 Storybook。

相关项目

Flat 安卓客户端

• https://github.com/netless-io/flat-android

Flat 服务端

• https://github.com/netless-io/flat-server

Flat 主页

• https://flat.whiteboard.agora.io/#download

传送门

• 开源地址：https://github.com/netless-io/flat

文章来源：https://www.cnblogs.com/cjsblog/p/11613708.html

假设有这样一个需求：在20亿个随机整数中找出某个数m是否存在其中，并假设32位操作系统，4G内存

在Java中，int占4字节，1字节=8位（1 byte = 8 bit）

如果每个数字用int存储，那就是20亿个int，因而占用的空间约为 (2000000000*4/1024/1024/1024)≈7.45 G

如果按位存储就不一样了，20亿个数就是20亿位，占用空间约为 (2000000000/8/1024/1024/1024)≈0.233 G

高下立判，无需多言

那么，问题来了，如何表示一个数呢？

刚才说了，每一位表示一个数，0表示不存在，1表示存在，这正符合二进制

这样我们可以很容易表示{1,2,4,6}这几个数：

计算机内存分配的最小单位是字节，也就是8位，那如果要表示{12,13,15}怎么办呢？

当然是在另一个8位上表示了：

这样的话，好像变成一个二维数组了

1个int占32位，那么我们只需要申请一个int数组长度为 int tmp[1+N/32] 即可存储，其中N表示要存储的这些数中的最大值，于是乎：

tmp[0]：可以表示0~31

tmp[1]：可以表示32~63

tmp[2]：可以表示64~95

。。。

如此一来，给定任意整数M，那么M/32就得到下标，M%32就知道它在此下标的哪个位置

首先，5/32=0，5%32=5，也是说它应该在tmp[0]的第5个位置，那我们把1向左移动5位，然后按位或

换成二进制就是

这就相当于 86 | 32 = 118

86 | (1

b[0] = b[0] | (1

也就是说，要想插入一个数，将1左移带代表该数字的那一位，然后与原数进行按位或操作

化简一下，就是 86 + (5/8) | (1

因此，公式可以概括为：p + (i/8)|(1

还是上面的例子，假设我们要6移除，该怎么做呢？

从图上看，只需将该数所在的位置为0即可

1左移6位，就到达6这个数字所代表的位，然后按位取反，最后与原数按位与，这样就把该位置为0了

b[0] = b[0] & (~(1

b[0] = b[0] & (~(1

假设，我们想知道3在不在，那么只需判断 b[0] & (1

假设我们要对0-7内的5个元素(4,7,2,5,3)排序（这里假设这些元素没有重复）,我们就可以采用Bit-map的方法来达到排序的目的。

要表示8个数，我们就只需要8个Bit（1Bytes），首先我们开辟1Byte的空间，将这些空间的所有Bit位都置为0，然后将对应位置为1。

最后，遍历一遍Bit区域，将该位是一的位的编号输出（2，3，4，5，7），这样就达到了排序的目的，时间复杂度O(n)。

优点:

• 运算效率高，不需要进行比较和移位；
• 占用内存少，比如N=10000000；只需占用内存为N/8=1250000Byte=1.25M

缺点:

• 所有的数据不能重复。即不可对重复的数据进行排序和查找。
• 只有当数据比较密集时才有优势

20亿个整数中找出不重复的整数的个数，内存不足以容纳这20亿个整数。

首先，根据“内存空间不足以容纳这05亿个整数”我们可以快速的联想到Bit-map。下边关键的问题就是怎么设计我们的Bit-map来表示这20亿个数字的状态了。其实这个问题很简单，一个数字的状态只有三种，分别为不存在，只有一个，有重复。因此，我们只需要2bits就可以对一个数字的状态进行存储了，假设我们设定一个数字不存在为00，存在一次01，存在两次及其以上为11。那我们大概需要存储空间2G左右。

接下来的任务就是把这20亿个数字放进去（存储），如果对应的状态位为00，则将其变为01，表示存在一次；如果对应的状态位为01，则将其变为11，表示已经有一个了，即出现多次；如果为11，则对应的状态位保持不变，仍表示出现多次。

最后，统计状态位为01的个数，就得到了不重复的数字个数，时间复杂度为O(n)。

这就是我们前面所说的了，int数组中的一个元素是4字节占32位，那么除以32就知道元素的下标，对32求余数（%32）就知道它在哪一位，如果该位是1，则表示存在。

Bitmap主要用于快速检索关键字状态，通常要求关键字是一个连续的序列（或者关键字是一个连续序列中的大部分）， 最基本的情况，使用1bit表示一个关键字的状态（可标示两种状态），但根据需要也可以使用2bit（表示4种状态），3bit（表示8种状态）。

Bitmap的主要应用场合：表示连续（或接近连续，即大部分会出现）的关键字序列的状态（状态数/关键字个数 越小越好）。

32位机器上，对于一个整型数，比如int a=1 在内存中占32bit位，这是为了方便计算机的运算。但是对于某些应用场景而言，这属于一种巨大的浪费，因为我们可以用对应的32bit位对应存储十进制的0-31个数，而这就是Bit-map的基本思想。Bit-map算法利用这种思想处理大量数据的排序、查询以及去重。

在数字没有溢出的前提下，对于正数和负数，左移一位都相当于乘以2的1次方，左移n位就相当于乘以2的n次方，右移一位相当于除2，右移n位相当于除以2的n次方。

>> 右移，相当于除以2的n次方，例如：64>>3 相当于64÷8=8

^ 异或，相当于求余数，例如：48^32 相当于 48%32=16

不使用第三方变量，交换两个变量的值

// 方式一
a = a + b;
b = a - b;
a = a - b;

// 方式二
a = a ^ b;
b = a ^ b;
a = a ^ b;

BitSet实现了一个位向量，它可以根据需要增长。每一位都有一个布尔值。一个BitSet的位可以被非负整数索引（PS：意思就是每一位都可以表示一个非负整数）。可以查找、设置、清除某一位。通过逻辑运算符可以修改另一个BitSet的内容。默认情况下，所有的位都有一个默认值false。

可以看到，跟我们前面想的差不多

用一个long数组来存储，初始长度64，set值的时候首先右移6位（相当于除以64）计算在数组的什么位置，然后更改状态位

别的看不懂不要紧，看懂这两句就够了：

int wordIndex = wordIndex(bitIndex);
words[wordIndex] |= (1L 

Bloom filter 是一个数据结构，它可以用来判断某个元素是否在集合内，具有运行快速，内存占用小的特点。

而高效插入和查询的代价就是，Bloom Filter 是一个基于概率的数据结构：它只能告诉我们一个元素绝对不在集合内或可能在集合内。

Bloom filter 的基础数据结构是一个 比特向量（可理解为数组）。

主要应用于大规模数据下不需要精确过滤的场景，如检查垃圾邮件地址，爬虫URL地址去重，解决缓存穿透问题等

如果想判断一个元素是不是在一个集合里，一般想到的是将集合中所有元素保存起来，然后通过比较确定。链表、树、散列表（哈希表）等等数据结构都是这种思路，但是随着集合中元素的增加，需要的存储空间越来越大；同时检索速度也越来越慢，检索时间复杂度分别是O(n)、O(log n)、O(1)。

布隆过滤器的原理是，当一个元素被加入集合时，通过 K 个散列函数将这个元素映射成一个位数组（Bit array）中的 K 个点，把它们置为 1 。检索时，只要看看这些点是不是都是1就知道元素是否在集合中；如果这些点有任何一个 0，则被检元素一定不在；如果都是1，则被检元素很可能在（之所以说“可能”是误差的存在）。

1、 首先需要 k 个 hash 函数，每个函数可以把 key 散列成为 1 个整数；

2、初始化时，需要一个长度为 n 比特的数组，每个比特位初始化为 0；

3、某个 key 加入集合时，用 k 个 hash 函数计算出 k 个散列值，并把数组中对应的比特位置为 1；

4、判断某个 key 是否在集合时，用 k 个 hash 函数计算出 k 个散列值，并查询数组中对应的比特位，如果所有的比特位都是1，认为在集合中。

dependency>
    groupId>com.google.guavagroupId>
    artifactId>guavaartifactId>
    version>28.1-jreversion>
dependency>