学习来源：极客时间-MySQL实战45讲，本人购买课程后依据图文讲解汇总成个人见解。

前言

经常会被问到这样一个问题：我的主机内存只有100G，现在要对一个200G的大表做全表扫描，会不会把数据库主机的内存用光了？

这个问题确实值得担心，被系统OOM（out of memory）可不是闹着玩的。但是，反过来想想，逻辑备份的时候，可不就是做整库扫描吗？如果这样就会把内存吃光，逻辑备份不是早就挂了？

所以说，对大表做全表扫描，看来应该是没问题的。但是，这个流程到底是怎么样的呢？

学习来源：极客时间-MySQL实战45讲，本人购买课程后依据图文讲解汇总成个人见解。

前言

在MySQL中有两个kill命令：一个是kill query +线程id，表示终止这个线程中正在执行的语句；一个是kill connection +线程id，这里connection可缺省，表示断开这个线程的连接，当然如果这个线程有语句正在执行，也是要先停止正在执行的语句的。

不知道你在使用MySQL的时候，有没有遇到过这样的现象：使用了kill命令，却没能断开这个连接。再执行show processlist命令，看到这条语句的Command列显示的是Killed。

你一定会奇怪，显示为Killed是什么意思，不是应该直接在show processlist的结果里看不到这个线程了吗？

今天，我们就来讨论一下这个问题。

其实大多数情况下，kill query/connection命令是有效的。比如，执行一个查询的过程中，发现执行时间太久，要放弃继续查询，这时我们就可以用kill query命令，终止这条查询语句。

还有一种情况是，语句处于锁等待的时候，直接使用kill命令也是有效的。我们一起来看下这个例子：

学习来源：极客时间-MySQL实战45讲，本人购买课程后依据图文讲解汇总成个人见解。

前言

在前面几篇文章中，我们介绍了MySQL的高可用架构。当然，传统的高可用架构是不能预防误删数据的，因为主库的一个drop table命令，会通过binlog传给所有从库和级联从库，进而导致整个集群的实例都会执行这个命令。

虽然我们之前遇到的大多数的数据被删，都是运维同学或者DBA背锅的。但实际上，只要有数据操作权限的同学，都有可能踩到误删数据这条线。

今天我们就来聊聊误删数据前后，我们可以做些什么，减少误删数据的风险，和由误删数据带来的损失。

为了找到解决误删数据的更高效的方法，我们需要先对和MySQL相关的误删数据，做下分类：

1. 使用delete语句误删数据行；

2. 使用drop table或者truncate table语句误删数据表；

3. 使用drop database语句误删数据库；

4. 使用rm命令误删整个MySQL实例。

Author: haoransun
Wechat: SHR—97
学习来源：极客时间-Nginx核心知识100讲，本人购买课程后依据视频讲解汇总成个人见解。

1 检查80端口是否被占用

yum install net-tools
netstat -ano | grep 80

2 Nginx命令行

Author: haoransun
Wechat: SHR—97
学习来源：极客时间-Nginx核心知识100讲，本人购买课程后依据视频讲解汇总成个人见解。

1 Nginx 配置语法

Author: haoransun
Wechat: SHR—97
学习来源：极客时间-Nginx核心知识100讲，本人购买课程后依据视频讲解汇总成个人见解。

章亦春文档

1 Nginx的三个主要应用场景

流程解析：
一个Web请求从红色的线走下来后，会先经过Nginx,再到应用服务（Tomcat/Django），再去访问Redis/MySQL这样的数据库，提供基本的数据功能，由此产生一个问题：应用服务由于要求开发效率高，所以它的运行效率很低，它的QPS/TPS/并发都是受限的，所以把这样的很多应用服务组成集群，向用户提供高可用性。当应用出现集群后，需要Nginx具有反向代理功能，将动态请求传导给应用服务，而应用服务构成集群，则又出现了两个需求，A：动态扩容。B：容灾。因此，反向代理必须具有负载均衡功能；其次，在这样的一个链路中，Nginx处于企业内网的边缘节点，随着网络链路的增长，用户体验的时延会增加，因此，如果能把一些所有用户看起来在一段时间内不变的动态内容缓存到Nginx中，由Nginx直接向用户提供访问，这样用户时延就会减少很多。反向代理引申出的另一个概念即是 缓存，加速我们的访问。（反向代理）

一些css/js/png等静态资源，是没有必要经由应用服务访问的，只需要通过本地文件 系统上放置的静态资源，直接由Nginx进行访问即可。（静态资源）

如果应用服务本身的性能有很多问题，但是数据库服务要比应用服务好的多，因为它的业务场景比较简单，并发性能/TPS都要远高于应用服务，因此可以使用Nginx直接访问数据库/Redis这样的数据库服务，利用Nginx强大的并发性能，实现Web防火墙这样复杂的业务功能（API服务）

Author: haoransun
Wechat: SHR—97
学习来源：极客时间-Nginx核心知识100讲，本人购买课程后依据视频讲解汇总成个人见解。

前言

通过访问日志，可以知晓用户的地址，网站的哪些部分最受欢迎。用户的浏览时间，对大多数用户的浏览器做出针对性优化。

Nginx会把每个用户访问的日志信息记录到指定的日志文件里，供网站管理员分析用户浏览行为等，此功能又ngx_http_log_module 模块负责。

前言

分布式事务指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。

如在微服务系统中，如果一个业务需要使用到不同的微服务，并且不同的微服务对应不同的数据库。

例如在下单场景下，库存和订单如果不在同一个节点上，就涉及分布式事务。

这个业务逻辑涉及到两个微服务，一个是库存服务（库存减一），另一个是订单服务（订单数加一），

如果在执行这个业务逻辑时没有使用分布式事务，当库存与订单其中一个出现故障时，就很可能出现这样的情况：库存数据库的值减少了1，但是订单数据库没有变化；或是库存没变化，多了一个订单，也就是出现了数据不一致现象。

所以在类似的场合下我们要使用分布式事务，保证数据的一致性。

1. 为什么使用分布式锁？

在讨论这个问题之前，我们先来看一个业务场景：

系统A是一个电商系统，目前是一台机器部署，系统中有一个用户下订单的接口，但是用户下订单之前一定要去检查一下库存，确保库存足够了才会给用户下单。

由于系统有一定的并发，所以会预先将商品的库存保存在redis中，用户下单的时候会更新redis的库存。

此时系统架构如下：

但是这样一来会产生一个问题：假如某个时刻，redis里面的某个商品库存为1，此时两个请求同时到来，其中一个请求执行到上图的第3步，更新数据库的库存为0，但是第4步还没有执行。

转载自 https://www.cnblogs.com/skorzeny/p/10409866.html

单机里面，完美解决锁与事务。

一、使用锁的原因分析：

1、使用锁的目的

————多个外部线程同时来竞争使用同一资源时，会彼此影响，导致混乱

————锁的目的，将资源的使用做排它性处理，使同一时间，仅一个线程能访问资源

2、并不是所有的资源，都无法同时服务多个线程 —— 比如，无状态的资源

3、无成员变量/成员变量不存在变化的类—- 就是无状态类 —– 这种类是线程安全的

4、有状态的对象，也不一定是不安全的

———- 如果状态变化是原子的（即没有中间变迁过程，变化不需要时间，没有中间态） —- 那么它一样是线程安全的

5、重要的概念，动作的原子性

6、总结：锁的本质

锁要解决的问题是 ——- 资源数据会不一致

锁要达成的目标是 ——- 让资源使用起来，像原子性一样

锁达成目标的手段 ——- 让使用者访问资源时，只能排队，一个一个地去访问资源