腾讯内部技术——SpringBoot微信点餐系统

架构

先后端分离:

​

部署架构：

​

补充：

setting.xml 文件的做用：settings.xml是maven的全局配置文件。而pom.xml文件是所在项目的局部配置。Settings.xml中包含相似本地仓储位置、修改远程仓储服务器、认证信息等配置。

maven的做用：借助Maven，可将jar包仅仅保存在“仓库”中，有须要该文件时，就引用该文件接口，不须要复制文件过来占用空间。

注：这个“仓库”应该就是本地安装maven的目录下的Repository的文件夹

分布式锁

线程锁：当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效，由于线程锁的实如今根本上是依靠线程之间共享内存实现的。如synchronized

进程锁：为了控制同一操做系统中多个进程访问某个共享资源。

分布式锁：当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。

分布式锁通常有三种实现方式：1. 数据库乐观锁；2. 基于Redis的分布式锁；3. 基于ZooKeeper的分布式锁。

乐观锁的实现：使用版本标识来肯定读到的数据与提交时的数据是否一致。提交后修改版本标识，不一致时能够采起丢弃和再次尝试的策略。在此我向你们推荐一个架构学习交流群。交流学习群号：948368769里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

分布式锁基于Redis的实现：(本系统锁才用的)

​

基本命令：

SETNX（SET if Not exist）：当且仅当 key 不存在，将 key 的值设为 value ，并返回1；若给定的 key 已经存在，则 SETNX 不作任何动做，并返回0。

GETSET：将给定 key 的值设为 value ，并返回 key 的旧值。先根据key获取到旧的value，再set新的value。

EXPIRE 为给定 key 设置生存时间,当 key 过时时，它会被自动删除。

加锁方式：

这里的jedis是Java对Redis的集成

jedis.set(String key, String value, String nxxx, String expx, int time)

错误的加锁方式1：若是程序在执行完setnx()以后忽然崩溃，致使锁没有设置过时时间。那么将会发生死锁。

Long result = jedis.setnx(Key, value);
if (result == 1) {
// 若在这里程序忽然崩溃，则没法设置过时时间，将发生死锁
jedis.expire(Key, expireTime);
}

错误的加锁方式2：分布式锁才用（Key，过时时间）的方式，若是锁存在，那么获取它的过时时间，若是锁的确已通过期了，那么得到锁，而且设置新的过时时间

错误分析：不一样的客户端之间须要同步好时间。

long expires = System.currentTimeMillis() + expireTime;
String expiresStr = String.valueOf(expires);
// 若是当前锁不存在，返回加锁成功
if (jedis.setnx(lockKey, expiresStr) == 1) {
return true;
}
// 若是锁存在，获取锁的过时时间
String currentValueStr = jedis.get(lockKey);
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
// 锁已过时，获取上一个锁的过时时间，并设置如今锁的过时时间
String oldValueStr = jedis.getSet(lockKey, expiresStr);
if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
// 考虑多线程并发的状况，只有一个线程的设置值和当前值相同，它才有权利加锁
return true;
}
}
// 其余状况，一概返回加锁失败
return false;

解锁：判断锁的拥有者后可使用 jedis.del(lockKey) 来释放锁。

分布式锁基于Zookeeper的实现

Zookeeper简介：Zookeeper提供一个多层级的节点命名空间（节点称为znode），每一个节点都用一个以斜杠（/）分隔的路径表示，并且每一个节点都有父节点（根节点除外）。例如，/foo/doo这个表示一个znode，它的父节点为/foo，父父节点为/，而/为根节点没有父节点。

​

client不论链接到哪一个Server，展现给它都是同一个视图，这是zookeeper最重要的性能。

Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫作Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步之后，恢复模式就结束了。状态同步保证了leader和Server具备相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务，实现中zxid是一个64位的数字。

Zookeeper的分布式锁原理

获取分布式锁的流程：

在获取分布式锁的时候在locker节点(locker节点是Zookeeper的指定节点)下建立临时顺序节点，释放锁的时候删除该临时节点。

客户端调用createNode方法在locker下建立临时顺序节点，而后调用getChildren(“locker”)来获取locker下面的全部子节点，注意此时不用设置任何Watcher。

客户端获取到全部的子节点path以后，若是发现本身建立的子节点序号最小，那么就认为该客户端获取到了锁。

若是发现本身建立的节点并不是locker全部子节点中最小的，说明本身尚未获取到锁，此时客户端须要找到比本身小的那个节点，而后对其调用exist()方法，同时对其注册事件监听器。

以后，让这个被关注的节点删除，则客户端的Watcher会收到相应通知，此时再次判断本身建立的节点是不是locker子节点中序号最小的，若是是则获取到了锁，若是不是则重复以上步骤继续获取到比本身小的一个节点并注册监听。

个人解释：A在Locker下建立了Node_n —>循环 ( 每次获取Locker下的全部子节点 —> 对这些节点按节点自增号排序顺序 —> 判断本身建立的Node_n是不是第一个节点 —> 若是是则得到了分布式锁 —> 若是不是监听上一个节点Node_n-1 等它释放掉分布式锁。)

@ControllerAdvice处理全局异常

Mybatis注解方式的使用：

@insert 用注解方式写SQL语句

分布式系统的下的Session

一、分布式系统：多节点，节点发送数据交互，不共享主内存，但经过网络发送消息合做。

分布式：不一样功能模块的节点

集群：相同功能的节点

二、Session 与token

服务端在HTTP头里设置SessionID而客户端将其保存在cookie

而使用Token时须要手动在HTTP头里设置，服务器收到请求后取出cookie进行验证。

都是一个用户一个标志

三、分布式系统中的Session问题：

高并发：经过设计保证系统可以同时并行处理不少请求。

当高并发量的请求到达服务端的时候经过负载均衡的方式分发到集群中的某个服务器，这样就有可能致使同一个用户的屡次请求被分发到集群的不一样服务器上，就会出现取不到session数据的状况

根据访问不一样的URL，负载到不一样的服务器上去

三台机器，A1部署类目，A2部署商品，A3部署单服务

通用方案：用Redis保存Session信息，服务器须要时都去找Redis要。登陆时保存好key-value，登出时让他失效

垂直扩展：IP哈希 IP的哈希值相同的访问同一台服务器

session的一致性：只要用户不重启浏览器，每次http短链接请求，理论上服务端都能定位到session，保持会话。

Redis做为分布式锁

高并发：经过设计保证系统可以同时并行处理不少请求。

同步：Java中的同步指的是经过人为的控制和调度，保证共享资源的多线程访问成为线程安全。

​

线程的Block状态：

a.调用join()和sleep()方法，sleep()时间结束或被打断

b.wait()，使该线程处于等待池,直到notify()/notifyAll()：不释放资源

​

此外，在runnable状态的线程是处于被调度的线程，Thread类中的yield方法可让一个running状态的线程转入runnable。

Q：为何wait,notify和notifyAll必须与synchronized一块儿使用？

Obj.wait()、Obj.notify必须在synchronized(Obj){…}语句块内。

A：wait就是说线程在获取对象锁后，主动释放对象锁，同时本线程休眠。

Q：Synchronized：

A：Synchronized就是非公平锁，它没法保证等待的线程获取锁的顺序。

公平和非公平锁的队列都基于锁内部维护的一个双向链表，表结点Node的值就是每个请求当前锁的线程。公平锁则在于每次都是依次从队首取值。

Spring + Redis缓存的两个重要注解：

@cacheable 只会执行一次，当标记在一个方法上时表示该方法是支持缓存的，Spring会在其被调用后将其返回值缓存起来，以保证下次利用一样的参数来执行该方法时能够直接从缓存中获取结果。在此我向你们推荐一个架构学习交流群。交流学习群号：948368769里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

@cacheput：与@Cacheable不一样的是使用@CachePut标注的方法在执行前不会去检查缓存中是否存在以前执行过的结果，而是每次都会执行该方法，并将执行结果以键值对的形式存入指定的缓存中。

对数据库加锁

乐观锁 与 悲观锁

悲观锁依赖数据库实现：

select * from account where name=”Erica” for update

这条sql 语句锁定了account 表中全部符合检索条件（name=”Erica”）的记录，使该记录在修改期间其它线程不得占有

代码层加锁：

String hql ="from TUser as user where user.name='Erica'";
Query query = session.createQuery(hql);
query.setLockMode("user",LockMode.UPGRADE); //加锁
List userList = query.list();//执行查询，获取数据

其它

@Data 相似于自动生成了Getter()、Setter()、ToString()等方法

JAVA1.8的新特性StreamAPI：Collectors中提供了将流中的元素累积到汇聚结果的各类方式

List<Menu> menus=Menu.getMenus.stream().collect
(Collectors.toList())

For - each 写法：

for each语句是java5新增，在遍历数组、集合的时候，for each拥有不错的性能。
public static void main(String[] args) {
String[] names = {"beibei", "jingjing"};
for (String name : names) {
System.out.println(name);
}
}

for each虽然能遍历数组或者集合，可是只能用来遍历，没法在遍历的过程当中对数组或者集合进行修改。

BindingResult：一个@Valid的参数后必须紧挨着一个BindingResult 参数，不然spring会在校验不经过时直接抛出异常

@Data
public class OrderForm {
@NotEmpty(message = "姓名必填")
private String name;
}

后台：

@RequestMapping("save")
public String save( @Valid OrderForm order,BindingResult result) {
//
if(result.hasErrors()){
List<ObjectError> ls=result.getAllErrors();
for (int i = 0; i < ls.size(); i++) {
log.error("参数不正确，OrderForm={}", order);
throw new SellException(
………… ,
result.getFeildError.getDefaultMessage()
)
System.out.println("error:"+ls.get(i));
}
}
return "adduser";
}

result.getFeildError.getDefaultMessage()可抛出“姓名必填” 的异常。

四、List转为Map

public class Apple {
private Integer id;
private String name;
private BigDecimal money;
private Integer num;
/*构造函数*/
}
List<Apple> appleList = new ArrayList<>();//存放apple对象集合
Apple apple1 = new Apple(1,"苹果1",new BigDecimal("3.25"),10);
Apple apple12 = new Apple(1,"苹果2",new BigDecimal("1.35"),20);
Apple apple2 = new Apple(2,"香蕉",new BigDecimal("2.89"),30);
Apple apple3 = new Apple(3,"荔枝",new BigDecimal("9.99"),40);
appleList.add(apple1);
appleList.add(apple12);
appleList.add(apple2);
appleList.add(apple3);
Map<Integer, Apple> appleMap = appleList.stream().collect(Collectors.toMap
(Apple::getId, a -> a,(k1,k2)->k1));

五、Collection的子类：List、Set

​

List：ArrayList、LinkedList 、Vector

List：有序容器，容许null元素，容许重复元素

Set：元素是无序的，不容许元素

最流行的是基于 HashMap 实现的 HashSet，由hashCode()和equals()保证元素的惟一性。**

能够用set帮助去掉List中的重复元素，set的构造方法的参数能够是List，构造后是一个去重的set

HashMap的补充：它不是Collection下的

Map可使用containsKey()/containsValue()来检查其中是否含有某个key/value。

HashMap会利用对象的hashCode来快速找到key。

插入过程：经过一个hash函数肯定Entry的插入位置index=hash(key),可是数组的长度有限,可能会发生index冲突，当发生了冲突时，会使用头插法，即为新来的Entry指向旧的Entry，成为一个链表。

每次插入时依次遍历它的index下的单链表，若是存在Key一致的节点，那么直接替换，而且返回新的值。

可是单链表不会一直增长元素，当元素个数超过8个时，会尝试将单链表转化为红黑树存储。

为什么加载因子默认为0.75？（0.75开始扩容）

答：经过源码里的javadoc注释看到，元素在哈希表中分布的桶频率服从参数为0.5的泊松分布