库存扣减问题一直是秒杀中最关键的一个点。如果把控不好，扣成负数，那可就麻烦了，如么如何保证不会出现超卖还能保证性能呢？

因为要完成产品的全文搜索这个功能，所以需要准备一下ES的环境。本节安装ELK。

ELK由Elasticsearch、Logstash和Kibana三部分组件组成。

从技术角度出发，注册一个网站，再高并发的时候，有可能出现用户名重复这样的问题（虽然一般情况下不会出现这种问题），如何解决呢？

在单体应用中，我们经常用http session去管理用户信息，但是到了分布式环境下，显然是不行的，因为session对于不同的机器是隔离的，而http本身是无状态的，那么就无法判断出用户在哪一个服务器上登陆的。这个时候就需要有一个独立的地方存储用户session。spring session可以做到无代码侵入的方式实现分布式session存储。

分布式环境下如何保证ID的不重复呢？一般我们可能会想到用UUID来实现嘛。但是UUID一般可以获取当前时间的毫秒数再加点随机数，但是在高并发下仍然可能重复。最重要的是，如果我要用这种UUID来生成分表的唯一ID的话，重复不谈，这种随机的字符串对于我们的innodb存储引擎的插入效率是很低的。所以我们生成的ID如果作为主键，最好有两种特性：分布式唯一和有序。

在开发中，springMVC全局异常+spring包扫描包隔离+spring事务传播这三个不可能不会遇到。下面来好好说说他们吧。

为了讲解redis分布式锁，我将引入一个场景：定时关单。因为往往订单服务是一个集群，那么定时器会同时触发这些集群去取消订单，显然是浪费机器资源的，所以目的是：只让其中一台机器去执行取消订单即可。这里可以用分布式锁来实现。

我们可以自己来实现一个redis分布式锁，但是如何用Redisson优雅地实现呢？本文探讨一下它的原理。

经常听到别人说事务传播行为，那到底什么是事务的传播行为呢？

对于并发场景下，推荐使用线程安全的 concurrentHashMap ，而不是 HashMap 或者是 HashTable .concurrentHashMap在JDK7和JDK8中的实现原理是不一样的。本文分别对其核心思想和方法进行阐述。