如何通过分库分表来优化数据库性能？

-- 原始代码，单表存储所有数据
SELECT * FROM orders WHERE user_id = 1;

 

通过分库分表，可以将数据分散到多个数据库实例，提高查询效率，降低单个数据库的压力。

-- 优化后的代码，分表存储数据
-- 假设将订单数据按用户ID进行分表
SELECT * FROM orders_1 WHERE user_id = 1;

 

 

同步（synchronous） IO和异步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分别是什么，到底有什么区别？

这个问题其实不同的人给出的答案都可能不同，比如wiki，就认为asynchronous IO和non-blocking IO是一个东西。这其实是因为不同的人的知识背景不同，并且在讨论这个问题的时候上下文(context)也不相同。所以，为了更好的回答这个问题，我先限定一下本文的上下文。

本文讨论的背景是Linux环境下的network IO。

本文最重要的参考文献是Richard Stevens的“UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking ”，6.2节“I/O Models ”，Stevens在这节中详细说明了各种IO的特点和区别，如果英文够好的话，推荐直接阅读。

Stevens的文风是有名的深入浅出，所以不用担心看不懂。本文中的流程图也是截取自参考文献。

Stevens在文章中一共比较了五种IO Model：

  • blocking IO
  • nonblocking IO
  • IO multiplexing
  • signal driven IO
  • asynchronous IO

由于signal driven IO在实际中并不常用，所以我这只提及剩下的四种IO Model。

再说一下IO发生时涉及的对象和步骤。

对于一个network IO (这里我们以read举例)，它会涉及到两个系统对象，一个是调用这个IO的process (or thread)，另一个就是系统内核(kernel)。当一个read操作发生时，它会经历两个阶段：

等待数据准备 (Waiting for the data to be ready)
将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)

记住这两点很重要，因为这些IO Model的区别就是在两个阶段上各有不同的情况。

blocking IO

在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样：

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。

对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。

当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。

所以，blocking IO的特点就是在IO执行的两个阶段都被block了。

non-blocking IO

linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子：

https://jsd.onmicrosoft.cn/gh/iGaoWei/codercdn@master/question/20240627/2024062710392961314.png

从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。

用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。

所以，用户进程其实是需要不断的主动询问kernel数据好了没有。

IO multiplexing

IO multiplexing这个词可能有点陌生，但是如果我说select，epoll，大概就都能明白了。有些地方也称这种IO方式为event driven IO。我们都知道，select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。

它的基本原理就是select/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：

https://jsd.onmicrosoft.cn/gh/iGaoWei/codercdn@master/question/20240627/2024062710393861880.png

当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。

这个图和blocking IO的图其实并没有太大的不同，事实上，还更差一些。因为这里需要使用两个system call (select 和 recvfrom)，而blocking IO只调用了一个system call (recvfrom)。但是，用select的优势在于它可以同时处理多个connection。

多说一句。所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。

在IO multiplexing Model中，实际中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。

Asynchronous I/O

linux下的asynchronous IO其实用得很少。先看一下它的流程：

https://jsd.onmicrosoft.cn/gh/iGaoWei/codercdn@master/question/20240627/2024062710394791838.png

用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。

然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。

到目前为止，已经将四个IO Model都介绍完了。现在回过头来回答最初的那几个问题：blocking和non-blocking的区别在哪，synchronous IO和asynchronous IO的区别在哪。

先回答最简单的这个：blocking vs non-blocking。前面的介绍中其实已经很明确的说明了这两者的区别。调用blocking IO会一直block住对应的进程直到操作完成，而non-blocking IO在kernel还准备数据的情况下会立刻返回。

在说明synchronous IO和asynchronous IO的区别之前，需要先给出两者的定义。Stevens给出的定义（其实是POSIX的定义）是这样子的：

A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
An asynchronous I/O operation does not cause the requesting process to be blocked;

两者的区别就在于synchronous IO做”IO operation”的时候会将process阻塞。按照这个定义，之前所述的blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO。

有人可能会说，non-blocking IO并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”IO operation”是指真实的IO操作，就是例子中的recvfrom这个system call。non-blocking IO在执行recvfrom这个system call的时候，如果kernel的数据没有准备好，这时候不会block进程。

 

但是，当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了，在这段时间内，进程是被block的。而asynchronous IO则不一样，当进程发起IO 操作之后，就直接返回再也不理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。

经过上面的介绍，会发现non-blocking IO和asynchronous IO的区别还是很明显的。在non-blocking IO中，虽然进程大部分时间都不会被block，但是它仍然要求进程去主动的check，并且当数据准备完成以后，也需要进程主动的再次调用recvfrom来将数据拷贝到用户内存。

而asynchronous IO则完全不同。它就像是用户进程将整个IO操作交给了他人（kernel）完成，然后他人做完后发信号通知。在此期间，用户进程不需要去检查IO操作的状态，也不需要主动的去拷贝数据。

最后，再举几个不是很恰当的例子来说明这四个IO Model:

有A，B，C，D四个人在钓鱼：

  • A用的是最老式的鱼竿，所以呢，得一直守着，等到鱼上钩了再拉杆；
  • B的鱼竿有个功能，能够显示是否有鱼上钩，所以呢，B就和旁边的MM聊天，隔会再看看有没有鱼上钩，有的话就迅速拉杆；
  • C用的鱼竿和B差不多，但他想了一个好办法，就是同时放好几根鱼竿，然后守在旁边，一旦有显示说鱼上钩了，它就将对应的鱼竿拉起来；
  • D是个有钱人，干脆雇了一个人帮他钓鱼，一旦那个人把鱼钓上来了，就给D发个短信。

哲学家就餐问题是一个经典的同步问题，描述了五个哲学家在吃饭和思考之间切换，且需要相邻的两把叉子。

面试官心理分析

其实这是分库分表之后你必然要面对的一个问题，就是 id 咋生成？因为要是分成多个表之后，每个表都是从 1 开始累加，那肯定不对啊，需要一个全局唯一的 id 来支持。所以这都是你实际生产环境中必须考虑的问题。

面试题剖析

基于数据库的实现方案

数据库自增 id

这个就是说你的系统里每次得到一个 id，都是往一个库的一个表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表里去写入。

这个方案的好处就是方便简单，谁都会用；缺点就是单库生成自增 id，要是高并发的话，就会有瓶颈的；如果你硬是要改进一下，那么就专门开一个服务出来，这个服务每次就拿到当前 id 最大值，然后自己递增几个 id，一次性返回一批 id，然后再把当前最大 id 值修改成递增几个 id 之后的一个值；但是无论如何都是基于单个数据库。

适合的场景：你分库分表就俩原因，要不就是单库并发太高，要不就是单库数据量太大；除非是你并发不高，但是数据量太大导致的分库分表扩容，你可以用这个方案，因为可能每秒最高并发最多就几百，那么就走单独的一个库和表生成自增主键即可。

设置数据库 sequence 或者表自增字段步长

可以通过设置数据库 sequence 或者表的自增字段步长来进行水平伸缩。

比如说，现在有 8 个服务节点，每个服务节点使用一个 sequence 功能来产生 ID，每个 sequence 的起始 ID 不同，并且依次递增，步长都是 8。

https://jsd.onmicrosoft.cn/gh/iGaoWei/codercdn@master/question/20240627/2024062710175914521.png

适合的场景：在用户防止产生的 ID 重复时，这种方案实现起来比较简单，也能达到性能目标。但是服务节点固定，步长也固定，将来如果还要增加服务节点，就不好搞了。

UUID

好处就是本地生成，不要基于数据库来了；不好之处就是，UUID 太长了、占用空间大，作为主键性能太差了；更重要的是，UUID 不具有有序性，会导致 B+ 树索引在写的时候有过多的随机写操作（连续的 ID 可以产生部分顺序写），还有，由于在写的时候不能产生有顺序的 append 操作，而需要进行 insert 操作，将会读取整个 B+ 树节点到内存，在插入这条记录后会将整个节点写回磁盘，这种操作在记录占用空间比较大的情况下，性能下降明显。

适合的场景：如果你是要随机生成个什么文件名、编号之类的，你可以用 UUID，但是作为主键是不能用 UUID 的。

UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf

获取系统当前时间

这个就是获取当前时间即可，但是问题是，并发很高的时候，比如一秒并发几千，会有重复的情况，这个是肯定不合适的。基本就不用考虑了。

适合的场景：一般如果用这个方案，是将当前时间跟很多其他的业务字段拼接起来，作为一个 id，如果业务上你觉得可以接受，那么也是可以的。你可以将别的业务字段值跟当前时间拼接起来，组成一个全局唯一的编号。

snowflake 算法

snowflake 算法是 twitter 开源的分布式 id 生成算法，采用 Scala 语言实现，是把一个 64 位的 long 型的 id，1 个 bit 是不用的，用其中的 41 bit 作为毫秒数，用 10 bit 作为工作机器 id，12 bit 作为序列号。

  • 1 bit：不用，为啥呢？因为二进制里第一个 bit 为如果是 1，那么都是负数，但是我们生成的 id 都是正数，所以第一个 bit 统一都是 0。
  • 41 bit：表示的是时间戳，单位是毫秒。41 bit 可以表示的数字多达 2^41 - 1，也就是可以标识 2^41 - 1 个毫秒值，换算成年就是表示69年的时间。
  • 10 bit：记录工作机器 id，代表的是这个服务最多可以部署在 2^10台机器上哪，也就是1024台机器。但是 10 bit 里 5 个 bit 代表机房 id，5 个 bit 代表机器 id。意思就是最多代表 2^5个机房（32个机房），每个机房里可以代表 2^5 个机器（32台机器）。
  • 12 bit：这个是用来记录同一个毫秒内产生的不同 id，12 bit 可以代表的最大正整数是 2^12 - 1 = 4096，也就是说可以用这个 12 bit 代表的数字来区分同一个毫秒内的 4096 个不同的 id。
0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000

微信小程序是一种由腾讯开发的应用程序软件，可在微信内直接使用，无需下载和安装。其优点如下：

  • 方便快捷，即用即走 。用户无需下载安装，通过微信扫描小程序二维码或搜索关键词即可打开使用，且小程序的启动速度较快。
  • 节约手机存储空间 。小程序无需安装，不占用手机内存，用户可以随时卸载不再需要的小程序。
  • 功能丰富 。小程序支持产品展示、页面跳转、下单支付等多元功能，足以应对日常生活服务。

其缺点如下：

  • 没有用户体系 。小程序无法形成和用户的链接，没有这种链接，就无法具有商业价值。
  • 不能完成复杂工作 。小程序的架构无法承载一些娱乐、文档、游戏的重度需求。
  • 开放性有限 。小程序不能跳转外链网址，影响了小程序的开放性。
  • 太过依赖微信 。小程序完全依赖于微信，具有一定的风险。

https://jsd.onmicrosoft.cn/gh/iGaoWei/codercdn@master/question/20240627/2024062710060373846.png

1). Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。
　　通常模型对象负责在数据库中存取数据。

2). View（视图）是应用程序中处理数据显示的部分。
　　通常视图是依据模型数据创建的。

3). Controller（控制器）是应用程序中处理用户交互的部分。
　　通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

最典型的MVC就是JSP + serverlet + javabean的模式

MVC的思想：Controller负责将Model的数据用View显示出来，换句话说就是在Controller里面把Model的数据赋值给View。

MVC的特点：实现关注点分离，即应用程序中的数据模型与业务和展示逻辑解耦。就是将模型和视图之间实现代码分离，松散耦合，使之成为一个更容易开发、维护和测试的客户端应用程序。

MVC的优点：

耦合度低，视图层和业务层分离

重用度高

生命周期成本低

可维护性高

部署快

MVC的缺点：

不适合小型项目的开发

视图与控制器间的过于紧密的连接，视图与控制器是相互分离，但却是联系紧密的部件，妨碍了他们的独立重用

降低了视图对模型数据的访问，依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

MVC的应用：主要用于中大型项目的分层开发。

跨站点请求伪造（Cross-Site Request Forgeries），冒充用户发起请求（在用户不知情的情况下）， 完成一些违背用户意愿的事情（如修改用户信息，删初评论等）。

1、可能造成危害：

  1. 利用已通过认证的用户权限更新设定信息等；
  2. 利用已通过认证的用户权限购买商品；
  3. 利用已通过的用户权限在留言板上发表言论。

2、防御：

  1. 验证码；强制用户必须与应用进行交互，才能完成最终请求。
  2. 尽量使用 post ，限制 get 使用；get 太容易被拿来做 csrf 攻击；
  3. 请求来源限制，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险。
  4. token 验证 CSRF 防御机制是公认最合适的方案。

使用token的原理：

  1. 第一步：后端随机产生一个 token，把这个token 保存到 session 状态中；同时后端把这个token 交给前端页面；
  2. 第二步：前端页面提交请求时，把 token 加入到请求数据或者头信息中，一起传给后端；
  3. 后端验证前端传来的 token 与 session 是否一致，一致则合法，否则是非法请求。

clickjacking： 点击劫持，是指利用透明的按钮或连接做成陷阱，覆盖在 Web 页面之上。然后诱使用户在不知情的情况下，点击那个连接访问内容的一种攻击手段。这种行为又称为界面伪装(UI Redressing) 。

大概有两种方式：

攻击者使用一个透明 iframe，覆盖在一个网页上，然后诱使用户在该页面上进行操作，此时用户将在不知情的情况下点击透明的 iframe 页面；
攻击者使用一张图片覆盖在网页，遮挡网页原有的位置含义。

一般步骤

黑客创建一个网页利用 iframe 包含目标网站；

隐藏目标网站，使用户无法无法察觉到目标网站存在；

构造网页，诱变用户点击特点按钮

用户在不知情的情况下点击按钮，触发执行恶意网页的命令。

防御
X-FRAME-OPTIONS；
X-FRAME-OPTIONS HTTP 响应头是用来给浏览器指示允许一个页面可否在<frame>,

<iframe> 或者 <object> 中展现的标记。

网站可以使用此功能，来确保自己网站内容没有被嵌到别人的网站中去，也从而避免点击劫持的攻击。
有三个值：

DENY：表示页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。

SAMEORIGIN：表示该页面可以在相同域名页面的 frame 中展示。

ALLOW-FROM url：表示该页面可以在指定来源的 frame 中展示。

 

什么是SQL 注入

SQL 注入，一般发生在注册、评论、添加等，只有有用户输入的地方，就有可能发生 SQL 注入。SQL 注入是一种常见的 Web 安全漏洞，攻击者会利用这个漏洞，可以访问或修改数据，利用潜在的数据库漏洞进行攻击。

所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将(恶意的)SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击.

SQL 注入危害

任意的账号都可以登录，可以进行任意的操作，粗暴点讲，就是随便来。

SQL注入分类

  • 数字型注入

当输入的参数为整数时，则有可能存在数字型漏洞。

  • 字符型注入

当输入参数为字符串时，则可能存在字符型注入漏洞。数字型与字符型注入最大的区别在于：数字型不需要单引号闭合，而字符型一般需要使用单引号来闭合。

字符型注入最关键的是如何闭合 SQL 语句以及注释多余的代码。

  • 其他类型

其实我觉得 SQL 注入只有两种类型：数字型与字符型。很多人可能会说还有如：Cookie 注入、POST 注入、延时注入等。

的确如此，但这些类型的注入归根结底也是数字型和字符型注入的不同展现形式或者注入的位置不同罢了。

以下是一些常见的注入叫法：

  • POST注入：注入字段在 POST 数据中
  • Cookie注入：注入字段在 Cookie 数据中
  • 延时注入：使用数据库延时特性注入
  • 搜索注入：注入处为搜索的地方
  • base64注入：注入字符串需要经过 base64 加密

SQL注入的防范措施

凡是用户输入的地方，我们都应该防止黑客攻击，永远不要相信用户的输入。所以对应的防御措施分别有：

  • 添加正则验证，使用正则表达式过滤传入的参数。
  • 屏蔽敏感词汇。
  • 字符串过滤。
  • DNS劫持（涉嫌违法）：修改运行商的 DNS 记录，重定向到其他网站。DNS 劫持是违法的行为，目前 DNS 劫持已被监管，现在很少见 DNS 劫持
  • HTTP劫持：前提有 HTTP 请求。因 HTTP 是明文传输，运营商便可借机修改 HTTP 响应内容（如加广告）。