qq_43626215的博客

然后分析，我的Nginx是部署在Docker上面的，但是后端Java服务是直接在Linux中用jar包运行的。挂载操作会直接将两个文件夹内容同步，若是直接用宿主机的空文件夹直接挂载到容器内部的配置文件目录上，会造成nginx容器配置文件目录被同步为空文件夹，进而导致容器启动失败。nginx.conf内容如下，主要是对各种配置进行映射，其中的目录是Docker容器中的目录，可以根据挂在目录映射进行相应的修改。到这里明白是什么问题了，我在前端的访问端口是后端项目的端口，而非nginx的监听端口。

每张表建议都有一个主键（主键索引），而且主键类型最好是int类型，建议自增主键（不考虑分布式系统情况下 雪花算法）为减少关联查询，创建合理的冗余字段（创建冗余字段还需要注意数据一致性问题）对于表中经常不被使用的字段或者存储数据比较多的字段，考虑折表。设计中间表，一般针对于统计分析功能，或者实时性不高的需求。对于字段太多的大表，考虑折表（比如一个表有100多个字段）

数据库优化纬度有四个：硬件升级、系统配置、表结构设计、SQL语句及索引。

每一个写事务，都会修改Buffer Pool，从而产生相应的Redo/Undo日志，在Buffer Pool中的页被刷到磁盘之前，这些日志信息都会先写入日志文件中，如果Buffer Pool中的脏页没有刷成功，此时数据库挂了，那在数据库再次启动之后，可以通过Redo 日志将其恢复出来，以保证脏页写的数据不会丢失。如果在事务中执行了一条没有索引条件的查询，引发全表扫描，把行级锁上升为全表记录锁定（等价于表级锁），多个这样的事务执行后，就很容易产生死锁和阻塞，最终应用系统会越来越慢，发生阻塞或死锁。

全表扫描：explain分析type属性为all全索引扫描：explain分析type属性为index索引过滤性不好：靠索引字段选型、数据量和状态、表设计频繁的回表查询开销：尽量少用select*，使用覆盖索引。

Undo：以为撤销或取消，以撤销操作为目的，返回指定某个状态的操作Undo Log：数据库事务开始之前，会将要修改的记录存放到Undo日志里，当事务回滚时或者数据库崩溃时，可以利用Undo日志，撤销未提交事务对数据库产生的影响Undo Log产生和销毁：Undo Log在事务开始前产生；事务在提交时，并不会立刻删除undo log，innodb会将该事务对应的undo log放入到删除列表中，后面会通过后台线程purge thread进行回收处理。Undo Log属于逻辑日志，记录一个变化的过程。

此文章由一次数据库被黑客删除而引发由于对于Linux操作、docker使用、MySQL原理这些都相对不是很熟悉，所以记录下来避免以后在工作中遇到类似的问题而惊慌失措。

Master选举是一个在分布式系统中非常常见的应用场景。分布式最核心的特性就是能够将具有独立计算能力的系统单元部署在不同的机器上，构成一个完整的分布式系统。而与此同时，实际场景中往往也需要在这些分布在不同机器上的独立系统单元中选出一个所谓的“老大”，在计算机中，我们称之为Master。在分布式系统中，Master往往用来协调集群中其他系统单元，具有对分布式系统状态变更的决定权。例如，在一些读写分离的应用场景中，客户端的写请求往往是由Master来处理的；

对于每一个事务请求，Zookeeper都会为其分配一个全局唯一的事务ID，用ZXID来表示，通常是一个64位的数字。在Zookeeper中，每一个数据节点都是一个ZNode，上图根目录下有两个节点，分别是：app1和app2，其中app1下面又有三个子节点，所有ZNode按层次化进行组织，形成这么一棵树，ZNode的节点路径标识方式和Unix文件系统路径非常相似，都是由一系列使用斜杠（/）进行分割的路径表示，开发人员可以向这个节点写入数据，也可以在这个节点下面创建子节点。

Zookeeper安装方式有三种，单机模式和集群模式以及伪集群模式。

分布式系统是同时跨越多给物理主机，独立运行的多个软件所组成的系统。类比一下，分布式系统就是一群人一起干活。人多力量大，每个服务器的算力是有限的，但是通过分布式系统，由n个服务器组成起来的集群，算力是可以无限扩张的。分布式系统的协调工作就是通过某种方式，让每个节点的信息能够同步和共享。这依赖于服务进程之间的通信。通过网络进行信息共享通过共享存储。

当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心服务正常运作或高效运作。整个架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用。博物馆：限制每天参观总人数以保护文物地铁安检：有若干安检口，乘客依次排队，工作人员根据安检快慢决定是否放任进去。

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。该框架提供了负载均衡，跟踪，智能监控，身份验证登功能，可以实现系统间的高效连接。和传统的单体架构相比，分布式多了一个远程服务之间的通信，不管是soa还是微服务，他们本质上都是对于业务服务的提炼和复用。

在高可用（HA）系统中，当联系两个节点的“心跳线”断开时（即两个节点断开联系时）。本来为一个整体、动作协调的HA系统，就分裂成为两个独立的节点（即两个独立的个体）。由于相互失去了联系，都以为是对方出了故障，两个节点上的HA软件像“裂脑人”一样，“本能”地争抢“共享资源”、争起“应用服务”。共享资源被瓜分、两边“服务”都起不来了；两边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）两个节点相互争抢共享资源，结果会导致系统混乱，数据损坏。

NWR是一种在分布式存储系统中用于控制一致性级别的一种策略。在亚马逊的云存储系统中，就应用NWR来控制一致性N：在分布式存储系统中，有多少份备份数据W：代表一次成功的更新操作要求至少有W份数据写入成功R：代表一次成功的读数据操作要求至少有R份数据成功读取Gossip协议也叫Epidemic协议（流行病协议）。原本用于分布式数据库中节点同步数据使用，后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。

CAP定理，它指出对于一个分布式计算系统来说，不可能同时满足以下三点。

通俗的理解，所谓分布式系统，就是一个业务拆分成多个子业务，分布在不同的服务器节点，共同构成的系统称为分布式系统，同一个分布式系统中的服务器节点在空间部署上是可以随意分布的，这些服务器可能放在不同的机柜中，也可能在不同的机房中，甚至分布在不同的城市。节点故障是分布式系统下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或“僵死”现象，根据经验来说，每个节点都有可能出现故障，并且经常发生。分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

Nettt的HTTP协议栈无论在性能还是在可靠性上，都表现优异，非常适合在非Web容器的场景下应用，相比传统的Tomcat、Jetty等Web容器，它更加轻量和小巧，灵活性和定制性也更好。粘包和拆包是TCP网络编程中不可避免的，无论是服务端还是客户端，当我们读取或者发送消息的时候，都需要考虑TCP底层的粘包/拆包机制。TCP是个“流”协议，所谓流，就是没有界限的一串数据。

NIO的类库和API繁杂，使用麻烦：需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等需要具备其他的额外技能：要熟悉Java多线程变成，因为NIO编程涉及到Reactor模式，你必须对多线程和网络编程非常熟悉，才能编写出高质量的NIO程序。开发工作量和难度都非常大：例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常流的处理等等。

Java NIO全称Java non-blocking IO，是指JDK提供的新API。从JDK1.4开始，Java提供了一系列改进的输入/输出的新特性，被统称为NIO（即New IO），是同步非阻塞的。NIO有三大核心部分：Channel（通道）、Buffer（缓冲区）、Selector（选择器）NIO是是面向缓冲区编程的。数据读取到一个缓冲区中，需要时可在缓冲区中前后移动，这就增加了处理过程中的灵活性，使用它可以提供非阻塞式的高伸缩性网络。