关于集群中的"脑裂"问题，之前已经在这里详细介绍过，下面重点说下Zookeeper脑裂问题的处理办法。ooKeeper是用来协调（同步）分布式进程的服务，提供了一个简单高性能的协调内核，用户可以在此之上构建更多复杂的分布式协调功能。脑裂通常会出现在集群环境中，比如ElasticSearch、Zookeeper集群，而这些集群环境有一个统一的特点，就是它们有一个大脑，比如ElasticSearch集群中有Master节点，Zookeeper集群中有Leader节点。

近期遇到一个spring注解事务失效的问题，先上代码（以下代码经过简化，只保留关键点）。

第一部分：具体问题

接下来上一下代码，大致介绍一下流程。

Controller

Controller里面使用@Autowired注入了一个serviceImpl，然后调用这个serviceImpl的业务方法。

ServiceImpl的属性

自动装配了另一个service和一个dao

重点看serviceImpl的方法（经过简化，只保留了关键点）

红框是两个insert数据库操作，需要事务管理

最下面的抛出异常是为了测试事务。

其中红框里面的super.addNew方法上有@Transactional(rollbackFor = Exception.class)注解。所以看上去并没有什么问题，但是每次抛出异常，数据库的操作都没有回滚。

问题大致就是这样，本来以为事情会很容易被解决，因为在网上看过很多事务失效的例子，各种原因被各种大神列举了很多次了。

第二部分：常规问题解决

普通事务失效原因：

1.如使用mysql且引擎是MyISAM，则事务会不起作用，原因是MyISAM不支持事务，可以改成InnoDB

2. 如果使用了spring+mvc，则context:component-scan重复扫描问题可能会引起事务失败。 （即父子容器）

3. @Transactional 注解开启配置，必须放到listener里加载，如果放到DispatcherServlet的配置里，事务也是不起作用的。

4. @Transactional 注解只能应用到 public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错，事务也会失效。

5. Spring团队建议在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。在接口上使用 @Transactional 注解，只能当你设置了基于接口的代理时它才生效。因为注解是 不能继承 的，这就意味着如果正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，而且对象也将不会被事务代理所包装。

以上五点摘抄自：Spring事务失效的原因

看到常规的原因，首先的解决思路如下

1.首先，数据库使用的是oracle，所以排除1

2.项目确实使用的是spring+mvc不过已经分开扫描了，mvc只扫描Controller和RestController，spring扫描排除这两个注解这样可以排除2,

3.事务管理器配置确实是放在spring容器里，用Listener加载的

4.方法是public

5.是在类的方法上使用的，非接口上

所以，常规的问题被我巧妙地全避开了。

第三部分：解决思路

这个事务失效问题是第一次出现，并没有广泛存在我们的系统中。于是和其他的事务方法对比，发现其他的事务方法都是通过Service.getInstance()方法获取到的实例，跟进去，发现getInstance方法是通过我们项目定义的工具类从xml里面getBean获取到的。看上去貌似没什么问题，getBean和使用@Autowired不都一样嘛，都能获取到bean。

打开日志debug级别，看能不能查到点什么细节。并且给方法入口和spring的事务管理器入口org.springframework.transaction.interceptor.TransactionInterceptor#invoke打上断点，然后运行到该事务方法。

首先在方法入口的断点处用evaluate expression执行AopUtils.isAopProxy这个方法来看一下注入的serviceImpl是否被代理了，结果是true。

继续执行，进入到spring事务管理器里面，然后一步步跟代码，获取TransactionInfo等，并没有发现什么可疑点，因为都已经进入到了spring事务管理器了，而spring几乎不会出bug，进入到方法第一行后，查看了下debug日志，发现有Creating new transaction with name [XXX]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; '',-java.lang.Exception，继续执行，执行到super.addNew方法时，debug日志又出现了一行 Creating new transaction with name [XXX]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; '',-java.lang.Exception，而且此XXX非刚才的XXX，意思是在第一个事务里面，又起了一个事务，但是我事务没有显示配置PROPAGATION，默认的是REQUIRED，为什么会又重新起一个事务呢，这里让我百思不得其解。于是我回过头又检查了一遍父子容器问题，是不是还是因为包扫描重复导致的呢，虽然如果是子容器（即MVC）的话，肯定不会进入到事务管理器，但我还是抱着侥幸心理检查了一遍，没有任何问题。

没找到问题所在，继续执行下去，发现跑出的异常被事务管理局接管了，debug日志也显示了transaction rollback。这就更奇怪了，既然事务都回滚了，数据是怎么插到数据库里的呢。我继续在插数据的那一行sql打上断点，重复执行，发现执行完这条sql的时候，数据就已经在数据库了，但是事务还没提交。。这又是怎么回事。这里我想到了会不会是数据库连接设置的autoCommit，于是重复执行，在spring的transaction源码里面打断点，发现事务管理器会自动把autoCommit关掉。

感觉这条追查的路已经堵死了。。反而产生了两个其他的问题，1.既然是PROPAGATION_REQUIRED，为什么会在事务里又起一个事务，2.既然事务都还没提交，你是怎么插入到数据库里的。。

想到最一开始观察到的，和其他事务起作用的方法差别在于，他们的成员变量是getInstance获得的，而这个有问题的是@Autowired注入的，那么是不是这里有问题呢，于是我把Autowired的全换成了getInstance获取在xml里面注册的bean，果然，事务起作用了。可是，这tm到底咋回事。。。Autowired和getBean不是一样么，为什么会出现两种截然不同的结果。刚好最近刚看完SpringIoc的源码，就决定追查到底。

第四部分：真相大白

理理思路，父容器先加载，子容器后加载，子容器在加载过程中会通过获取到父容器。

请求到达应用后，Controller会先被初始化，然后他的私有属性serviceImpl会被 inject，实质上是会被父容器inject，然后循环注入serviceImpl私有属性的私有属性。。一直循环直到所有的bean都被实例化。事务管理器也在父容器中定义，貌似没有问题，事实也证明了，事务管理器确实代理了目标方法。

然后深入看了下getInstance方法，这个方法是通过项目的一个工具类的getBean方法工作的，工具类的getBean方法实际上是new了一个ClassPathXmlApplicationContext，然后调用他的getBean方法，那么看到这里好像一切都明朗了。。

@Autowired自动装配的是web.xml里面定义的Listener加载的父容器里的bean，getInstance是自己定义的第二个容器获取到的bean，那么事务管理器也是一样，实际上有两个事物管理器，第一个是webxml加载父容器的，第二个是工具类加载的容器的。所以才会出现在一个事务中又起一个事务，因为容器2不知道方法已经在容器1起了一个事务，我所看到的事务没提交也是看到的容器1起的事务没提交。

如果我再仔细缕一遍全流程就会发现，dao里面还封装了一层mybatis的sqlsession，这里使用的是工具类的getBean方法。

如果再仔细看一下debug日志的话，就会发现启动应用的时候，每个xml都被加载了两次，一次是webxml的父容器，一次是工具类new加载的。

终章：结论

遇到事务失效的时候，先看一下是否被事务管理器接管了，如果有，那么多半是容器的问题，这里并不一定是父子容器，也有可能是父父容器。。

借用《黑客与画家》的一句话：如果自己就是潮水的一部分，又怎么能看见潮流的方向呢。

当遇到问题时，不要迷在某个局部，要跳出来，先把整个流程理清。

最后再说一句，开启了上帝视角之后，感觉这问题实在是很简单，不过解决过程中花费了我本人非常多时间（不少于十小时）。

希望这篇博客可以给有问题的朋友带来一点思路。

1.常用限流方法
对于一个应用系统来说一定会有极限并发/请求数，即总有一个TPS/QPS阀值，如果超了阀值则系统就会不响应用户请求或响应的非常慢，因此我们最好进行过载保护，防止大量请求涌入击垮系统。

常见的限流方法有：

容器限流

常见的web容器其实也具备限流的功能。

以Tomcat容器为例，其Connector 其中一种配置有如下几个参数：

acceptCount：如果Tomcat的线程都忙于响应，新来的连接会进入队列排队，如果超出排队大小，则拒绝连接；

maxConnections： 瞬时最大连接数，超出的会排队等待；

maxThreads：Tomcat能启动用来处理请求的最大线程数，如果请求处理量一直远远大于最大线程数则可能会僵死。

限流总资源数

如果有的资源是稀缺资源（如数据库连接、线程），而且可能有多个系统都会去使用它，那么需要限制应用；可以使用池化技术来限制总资源数：连接池、线程池。比如分配给每个应用的数据库连接是100，那么本应用最多可以使用100个资源，超出了可以等待或者抛异常。

限流某个接口的总并发/请求数

如果接口可能会有突发访问情况，但又担心访问量太大造成崩溃，如抢购业务；这个时候就需要限制这个接口的总并发请求数了；因为粒度比较细，可以为每个接口都设置相应的阀值。可以使用Java中的AtomicLong进行限流：

try {
if(atomic.incrementAndGet() > 限流数) {
//拒绝请求
}
//处理请求
} finally {
atomic.decrementAndGet();
}

利用Netflix的hystrix限流

2.漏桶算法 VS 令牌桶算法
2.1 漏桶算法(Leaky Bucket)
漏桶算法(Leaky Bucket)：水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下:

可见这里有两个变量,一个是桶的大小,支持流量突发增多时可以存多少的水(burst),另一个是水桶漏洞的大小(rate)。

2.2 令牌桶算法(Token Bucket)
令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法,更加容易理解.随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了.新请求来临时,会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务.

令牌桶的另外一个好处是可以方便的改变速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量.

2.3 漏桶算法VS令牌桶算法
令牌桶是按照固定速率往桶中添加令牌，请求是否被处理需要看桶中令牌是否足够，当令牌数减为零时则拒绝新的请求；

漏桶则是按照常量固定速率流出请求，流入请求速率任意，当流入的请求数累积到漏桶容量时，则新流入的请求被拒绝；

令牌桶限制的是平均流入速率（允许突发请求，只要有令牌就可以处理，支持一次拿3个令牌，4个令牌），并允许一定程度突发流量；

漏桶限制的是常量流出速率（即流出速率是一个固定常量值，比如都是1的速率流出，而不能一次是1，下次又是2），从而平滑突发流入速率；

令牌桶允许一定程度的突发，而漏桶主要目的是平滑流入速率；

两个算法实现可以一样，但是方向是相反的，对于相同的参数得到的限流效果是一样的。

3.Guava实现平滑限流
3.1Guava是什么
Guava是一个开源的Java库，其中包含谷歌很多项目使用的核心库。这个库是为了方便编码，并减少编码错误。这个库提供用于集合，缓存，支持原语，并发性，常见注解，字符串处理，I/O和验证的实用方法。

3.2Guava RateLimiter实现平滑限流
Guava RateLimiter提供了令牌桶算法实现：平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现。

平滑突发限流：

/**
* 平滑突发限流(SmoothBursty)
*/
public class SmoothBurstyRateLimitTest {
public static void main(String[] args) {
//QPS = 5，每秒允许5个请求
RateLimiter limiter = RateLimiter.create(5);
//limiter.acquire() 返回获取token的耗时，以秒为单位
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
}
}

0.0
0.19667
0.195784
0.194672
0.195658
0.195285
/**
* 平滑突发限流(smoothbursty)
*/
public class SmoothBurstyRateLimitTest02 {

public static void main(String[] args) {
//每秒允许5个请求，表示桶容量为5且每秒新增5个令牌，即每隔0.2毫秒新增一个令牌
RateLimiter limiter = RateLimiter.create(5);
//一次性消费5个令牌
System.out.println(limiter.acquire(5));
//limiter.acquire(1)将等待差不多1秒桶中才能有令牌
System.out.println(limiter.acquire(1));
//固定速率
System.out.println(limiter.acquire(1));
//固定速率
System.out.println(limiter.acquire(1));
//固定速率
System.out.println(limiter.acquire(1));
}
}
/**
* 平滑突发限流(smoothbursty)
*/
public class SmoothBurstyRateLimitTest03 {

public static void main(String[] args) {
//每秒允许5个请求，表示桶容量为5且每秒新增5个令牌，即每隔0.2毫秒新增一个令牌
RateLimiter limiter = RateLimiter.create(5);
//第一秒突发了10个请求
System.out.println(limiter.acquire(10));
//limiter.acquire(1)将等待差不多2秒桶中才能有令牌
System.out.println(limiter.acquire(1));
//固定速率
System.out.println(limiter.acquire(1));
//固定速率
System.out.println(limiter.acquire(1));
//固定速率
System.out.println(limiter.acquire(1));
}
}
平滑预热限流：

/**
* 平滑预热限流(SmoothWarmingUp)
*/
public class SmoothWarmingUp {
public static void main(String[] args) {
//permitsPerSecond:每秒新增的令牌数 warmupPeriod:从冷启动速率过渡到平均速率的时间间隔
//系统冷启动后慢慢的趋于平均固定速率（即刚开始速率慢一些，然后慢慢趋于我们设置的固定速率）
RateLimiter limiter = RateLimiter.create(10, 1000, TimeUnit.MILLISECONDS);
for(int i = 0; i < 10;i++) {
//获取一个令牌
System.out.println(limiter.acquire(1));
}
}
}
秒杀场景：

/**
* 秒杀场景模拟
*/
public class MiaoShaTest {

public static void main(String[] args) throws InterruptedException {

//限流，每秒允许10个请求进入秒杀
RateLimiter limiter = RateLimiter.create(10);

for (int i = 0; i < 100; i++) {
//100个线程同时抢购
new Thread(() -> {
//每个秒杀请求如果100ms以内得到令牌，就算是秒杀成功，否则就返回秒杀失败
if (limiter.tryAcquire(50, TimeUnit.MILLISECONDS)) {
System.out.println("恭喜您，秒杀成功");
} else {
System.out.println("秒杀失败，请继续努力");
}
}).start();
//等待新的令牌生成
Thread.sleep(10);
}
}
}
测试demo地址：https://github.com/online-demo/yunxi-guava
————————————————
版权声明：本文为CSDN博主「ShiXueTanLang」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ShiXueTanLang/article/details/80960208

----------------

三种常见的限流算法

public class CounterTest {
    public long timeStamp = getNowTime();
    public int reqCount = 0;
    public final int limit = 100; // 时间窗口内最大请求数
    public final long interval = 1000; // 时间窗口ms

    public boolean grant() {
        long now = getNowTime();
        if (now < timeStamp + interval) {
            // 在时间窗口内
            reqCount++;
            // 判断当前时间窗口内是否超过最大请求控制数
            return reqCount <= limit;
        } else {
            timeStamp = now;
            // 超时后重置
            reqCount = 1;
            return true;
        }
    }

    public long getNowTime() {
        return System.currentTimeMillis();
    }
}

来源： https://www.cnblogs.com/linjiqin/p/9707713.html

前言

xss攻击(跨站脚本攻击)：攻击者在页面里插入恶意脚本代码，用户浏览该页面时，脚本代码就会执行，达到攻击者的目的。原理就是：攻击者对含有漏洞的服务器注入恶意代码，引诱用户浏览受到攻击的服务器，并打开相关页面，执行恶意代码。
xss攻击方式：一、反射性攻击，脚本代码作为url参数提交给服务器，服务器解析执行后，将脚本代码返回给浏览器，最后浏览器解析执行攻击代码；二、存储性攻击，和发射性攻击的区别是，脚本代码存储在服务器，下次在请求时，不用再提交脚本代码。其中一个示例图如下所示：

CSRF攻击：跨站请求伪造攻击，CSRF是一种欺骗受害者提交恶意请求的攻击，并劫持受害者的身份和特权，并以受害者的身份访问未授权的信息和功能。序列图如下所示：

同步器Token

解决XSS攻击和CSRF攻击的一个推荐方法就是同步器Token，就是在post的请求中，增加一个token，每次请求到来，服务器都会验证请求中的token和服务器期望的值是否一致，如果不一致，服务器将请求视为非法的，整个过程的示例图如下所示：

在spring security中如果使用的是 @EnableWebMvcSecurity而不是@EnableWebSecurity，同步器Token是默认打开的，通过http().csrf().disable()可以关闭同步器token功能。spring security发现token无效后，会返回一个403的访问拒绝，不过可以通过配置AccessDeniedHandler类处理InvalidCsrfTokenException异常来定制行为。

spring security虽然默认是打开同步器token保护的，但是也提供了一个显示打开的行为即http().csrf(),同时需要在html的form表单中添加以“<input type="hidden"name="${_csrf.parameterName}" value="${_csrf.token}"/>”

如果请求的是json或ajax请求，如何使用同步器token防护那？
json请求的话，我们可以在header的元数据中添加token防护，代码如下所示：

<head>
<meta name="_csrf" content="${_csrf.token}"/>
<!-- default header name is X-CSRF-TOKEN -->
<meta name="_csrf_header" content="${_csrf.headerName}"/>
...
</head>

ajax请求的话，可是使用如下代码：

$(function () {
var token = $("meta[name='_csrf']").attr("content");
var header = $("meta[name='_csrf_header']").attr("content");
$(document).ajaxSend(function(e, xhr, options) {
xhr.setRequestHeader(header, token);
});
});

Synchronizer Token的常见问题
1.超时
因为token是存储在httpsession中的，所以token存在超时的问题，一旦超时，则配置的accessDeniedHandler将接受一个异常，或者spring security直接拒绝访问；
2.登录
为了防止伪造的登录请求，在登录的form中也需要添加token，而token又是存储在HttpSession中，也就是说一旦发现token属性，就会创建一个HttpSession，这和无状态架构模式可能会产生一些冲突；
3.注销
添加CSRF将更新LogoutFilter过滤器，使其只使用HTTP POST。这确保了注销需要一个CSRF令牌，并且恶意用户不能强制注销您的用户。也就是说，注销不再是一个get请求，而是一个post请求；

spring security支持的安全response header

spring security 支持的response header 包括：Cache-Control,Content-type options,HTTP Strict Transport Security,X-Frame-Options,X-XSS-Protection 如果你使用的是WebSecurityConfigurerAdapter 配置方式，则这些头都是默认支持的，你可以通过调用 http.header().disable()关闭这些缺省的头。当然你也可以单独配置，但是如果你单独配置的话，只有你配置的头会起作用，其他的头都不再默认支持了。下面分别来讨论一下这些响应header的含义；

Cache-Control
如果不加任何控制，浏览器通常会缓存你的认证相关信息，这在一定程度上会造成你的信息泄露，因此在默认情况下，spring security会在响应头里加入缓存控制如下所示：

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0

当然你也可以通过 http.header().cacheControl()方法单独打开缓存控制，你也可以通过HttpServletResponse.setHeader(String,String)方法对特殊的响应做处理，从而确保css js 图片能够合适地被缓存，在spring mvc中，可以通过配置进行设置，下面的代码对所有的资源都增加了缓存：

@EnableWebMvc
public class WebMvcConfiguration
     extends WebMvcConfigurerAdapter {
        @Override
        public void addResourceHandlers(
        ResourceHandlerRegistry registry) {
        registry
        .addResourceHandler("/resources/**")
        .addResourceLocations("/resources/")
        .setCachePeriod(3_155_6926);
        }
// ...
}

Content-type Options

历史上很多很多浏览器都能可以通过对请求类型的content进行嗅探，猜测请求类型，从而提高用户体验，但是这会带来XSS攻击。例如有些站点允许用户向其提交有效的postScript脚本，并查看他。恶意用户可能提交一个有效的js文件，并使用它执行XSS攻击。spring security默认是禁止进行嗅探的。

HTTP Strict Transport Security
当你访问一个站点是，例如www.baidu.com，省略了https协议，潜在的你会受到中间人攻击，为了减少这种情况，就是告知浏览器，当你输入某个地址时，应该使用https协议。如何让浏览器该host是一个hsts站点那？其中一种方法就是，增加Strict-Transport-Security 到响应头中，如下例所示：

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

上述例子告知浏览器，该站点在一年内访问都使用https协议，includeSubDomains说明该站点的子域名也使用https协议访问。

X-frame-optiont

X-Frame-Options HTTP 响应头是用来给浏览器指示允许一个页面可否在 <frame>, <iframe> 或者 <object> 中展现的标记。网站可以使用此功能，来确保自己网站的内容没有被嵌到别人的网站中去，也从而避免了点击劫持 (clickjacking) 的攻击。
X-Frame-Options 有三个值: DENY 表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。SAMEORIGIN 表示该页面可以在相同域名页面的 frame 中展示。ALLOW-FROM uri表示该页面可以在指定来源的 frame 中展示。
Spring security默认是使用DENY，即拒绝在frame中展示，从而避免点击劫持的攻击，当然你也可以进行单独设置或对X-Frame-Option设置特殊的值。

Customer Header

Spring Security有一些机制，可以方便地向应用程序添加更常见的安全头。但是，它还提供了允许添加自定义头的钩子。有时，您希望将自定义安全头插入到您的应用程序中，而该特性并没有被支持。例如，您可能希望尽早支持内容安全策略，以确保资源只能从相同的源加载。由于对内容安全策略的支持还没有最终确定，浏览器使用两个常见的扩展头之一来实现这个特性。这意味着我们将需要注入两次策略。下面的代码片段中可以看到一个头的示例：

X-Content-Security-Policy: default-src 'self'
X-WebKit-CSP: default-src 'self'
@Override
protected void configure(HttpSecurity http) throws Exception {
        http.headers()
        .addHeaderWriter(
        new StaticHeadersWriter(
        "X-Content-Security-Policy",
        "default-src 'self'"))
        .addHeaderWriter(
        new StaticHeadersWriter(
        "X-WebKit-CSP",
        "default-src 'self'"));
}

当名称空间或Java配置不支持您想要的头部时，您可以创建一个自定义的HeadersWriter实例，甚至可以提供HeadersWriter的自定义实现。让我们看一个使用XFrameOptionsHeaderWriter的自定义实例的示例。也许您希望允许为相同的起源构建内容框架。将策略属性设置为SAMEORIGIN很容易支持这一点：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.headers()
    .addHeaderWriter(
    new XFrameOptionsHeaderWriter(
    XFrameOptionsMode.SAMEORIGIN));
}

有时，您可能只想为某些请求编写一个header。例如，您可能只想保护您的登录页面。您可以使用DelegatingRequestMatcherHeaderWriter类来这样做。

@Override
protected void configure(HttpSecurity http) throws Exception {
    DelegatingRequestMatcherHeaderWriter headerWriter =
    new DelegatingRequestMatcherHeaderWriter(
    new AntPathRequestMatcher("/login"),
    new XFrameOptionsHeaderWriter());
    http.headers()
    .addHeaderWriter(headerWriter);
}

1. port

https://blog.csdn.net/m0_37797416/article/details/83505663