基于SpringCloud的广告系统设计与实现（三）

一、广告系统业务需求

广告投放数据的核心要素

• 用户账户 -> 最高层级，用于定义广告主或代理商，只有有了用户才会有接下来的数据投放

• 推广计划 -> 一类品牌或产品广告投放的规划，自身并不定义太多关于广告自身的信息，它会将信息打包下放到推广单元层级

• 推广单元 -> 一个确定的广告投放策略，描述了投放广告的规则信息

• 推广单元维度限制 -> 广告投放会有一些限制条件，例如只投放到北京、上海地区，对一些关键字进行投放等等 （这可能是比较难理解的概念，需要大家好好的思考）

• 广告创意 -> 展示给用户看到的数据，可以是图片、文本或者一段视频

二、业务系统开发注意

1.@SpringBootApplication 与@SpringCloudApplication

@SpringBootApplication 、@SpringCloudApplication，这两个注解不是一个功能，他们都是组合注解，但是，你可以看到它们名字的区别。一个是 Boot，一个是 Cloud。

    注解 @SpringCloudApplication 包括：@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker，分别是 SpringBoot 注解、注册服务中心 Eureka 注解、断路器注解。对于SpringCloud 来说，这是每一微服务必须应有的三个注解，所以才推出了 @SpringCloudApplication 这一注解集合。    

    所以，当你的工程只是一个 SpringBoot 工程，那么，只需要加上 @SpringBootApplication 注解就可以了；如果你的工程需要服务发现，那么，无疑，需要添加 @SpringCloudApplication 注解。

2.主类上的注解：

    @EnableFeignClients：让当前的工程开启 Feign 的功能；

    @EnableCircuitBreaker：让当前的工程允许熔断；

    @EnableEurekaClient：让当前的工程作为 Eureka Client（相对于 Eureka Server 而言）

3.MyBatis 与 Spring Data Jpa 对比：

    1. MyBatis 的优势在于 SQL 的自由度上，SQL优化和返回对象的大小都是可控的；

    2. Spring Data Jpa 在开发效率上会更高，不需要编写大量的 SQL

    其实，在实际的企业级开发中，MyBatis 和 Spring Data Jpa 的选择上并没有太多考虑，可能是项目自身的约束，也可能是个人的开发习惯。对于当前的项目来说，完全可以将 Jpa 的方式自行替换成 MyBatis。

 JPA 我们在使用的时候编写的是接口，在实现上，JPA 会通过动态代理给我们生成对应的查询类，所以，比你直接使用 SQL 型的查询肯定要效率低一些。不过，这大大方便了我们的编码过程，性能方面，除非你有很高并发的需求，否则，忽略不计。

4.业务系统在网关中的配置

业务系统application.yml

server:
  port: 7000
  servlet:
    context-path: /ad-sponsor

网关配置application.yml：

zuul:
  prefix: /imooc
  routes:
    sponsor:
      path: /ad-sponsor/**
      serviceId: eureka-client-ad-sponsor
      strip-prefix: false

这段代码是基于Spring Cloud Zuul的配置，用于定义Zuul网关的路由规则。以下是对这段配置的详细解析：

配置解析

1. zuul.prefix: /imooc

• 作用：为所有通过Zuul网关的请求添加一个统一的前缀/imooc。

• 示例：如果客户端请求http://<gateway-host>/imooc/ad-sponsor/...，则该请求会被Zuul网关处理。

2. routes.sponsor

• 定义了一个路由规则，名称为sponsor。

3. path: /ad-sponsor/**

• 作用：定义了该路由规则匹配的路径模式。

• 含义：所有以/ad-sponsor/开头的请求路径都会被匹配到这个路由规则。

• 示例：请求路径/imooc/ad-sponsor/api/v1/some-endpoint会被匹配到这个路由。

4. serviceId: eureka-client-ad-sponsor

• 作用：指定当请求匹配到/ad-sponsor/**时，Zuul网关会将请求转发到Eureka服务注册中心中名为eureka-client-ad-sponsor的服务。

• 含义：eureka-client-ad-sponsor是服务提供者在Eureka服务注册中心注册时的服务ID。

• 示例：如果eureka-client-ad-sponsor服务的实际地址是http://localhost:8081，则请求http://<gateway-host>/imooc/ad-sponsor/api/v1/some-endpoint会被转发到http://localhost:8081/api/v1/some-endpoint。

5. strip-prefix: false

• 作用：控制是否在转发请求时去掉匹配的前缀。

• 含义：false表示不会去掉匹配的前缀/ad-sponsor/。

• 示例：请求http://<gateway-host>/imooc/ad-sponsor/api/v1/some-endpoint会被完整转发到http://localhost:8081/ad-sponsor/api/v1/some-endpoint。

总结

这段配置的作用是：

1. 定义了一个路由规则sponsor，匹配所有以/imooc/ad-sponsor/开头的请求。

2. 将匹配到的请求转发到Eureka服务注册中心中名为eureka-client-ad-sponsor的服务。

3. 在转发请求时，保留原始请求的路径（不去掉/ad-sponsor/前缀）。

注意事项

1. 服务注册：确保eureka-client-ad-sponsor服务已经正确注册到Eureka服务注册中心。

2. 路径匹配：客户端请求的路径必须以/imooc/ad-sponsor/开头，否则不会匹配到该路由规则。

3. 转发路径：由于strip-prefix: false，服务提供者需要能够处理完整的路径（包括/ad-sponsor/前缀）。

5.数据库表主键 

目前的表设计主键大多都是 int 或者 bigint，极少数才会使用 string 类型的。整数类型占用空间少，且索引速度快。而且对于绝大多数场景来说，int 类型有 20 亿的上限，基本上都是够用的。

三、MySQL

1.慢查询

如何处理慢查询

一般数据表查询，超过一分钟的都是不可以接受的了。可以考虑从两方面去解决这个问题：

    1. 根据查询条件建立对应的索引

    2. 将数据构造成索引放在 redis 这样的缓存里面

常见的处理方法：

1.添加索引，需要经常查询的字段都要添加，主键本身就是索引，按照主键查询记录效率是最高的；如果有多个字段都需要有索引，且是同时查询（即 where 条件有多个），一定要使用联合索引。
2. 避免使用 *，指定具体字段。如果表中包含的列特别多（例如超过20个），或者其中的几列存储的数据过大（例如 mediumtext 类型）。那么，只查询需要的列，不要使用 select *。
3. 用exists替代in，当然也可以用not exists替代not in，exists 会比 in 的查询效率高，数据量大的时候会有明显的速度提升。
4. 避免使用like，能不用模糊查询就不用，使用 like 时，很多情况下不能使用到索引。所以，效率会降低很多，不要把耗时的操作放在数据库里做，即能不用模糊查询就不用。

2.索引

CREATE INDEX 索引名 ON 表名(列名1，列名2,...);                  -- 创建索引
ALTER TABLE 表名 ADD INDEX 索引名 (列名1，列名2,...);            -- 修改表
CREATE TABLE 表名 ( [...], INDEX 索引名 (列名1，列名 2,...) );  -- 创建表时指定索引

CREATE UNIQUE INDEX 索引名 ON 表名(列名1，列名2,...);           -- 创建索引
ALTER TABLE 表名 ADD UNIQUE 索引名 (列名1，列名2,...);           -- 修改表
CREATE TABLE 表名( [...], UNIQUE 索引名 (列名1，列名2,...) );   -- 创建表时指定索引

CREATE TABLE 表名( [...], PRIMARY KEY (列名1，列名2,...) );    -- 创建表的时候指定
ALTER TABLE 表名 ADD PRIMARY KEY (列名1，列名2,...);            -- 修改表

-- 删除 talbe_name 中的索引 index_name
DROP INDEX index_name ON talbe_name
ALTER TABLE table_name DROP INDEX index_name
-- 删除主键索引，因为一个表只可能有一个PRIMARY KEY索引，因此不需要指定索引名
ALTER TABLE table_name DROP PRIMARY KEY

show index from table_name;
show keys from table_name;

-- 核心字段的解释
-- Table：表的名称
-- Non_unique：如果索引不能包括重复词，则为0。如果可以，则为1
-- Key_name：索引的名称
-- Seq_in_index：索引中的列序列号，从1开始
-- Column_name：列名称
-- Collation：列以什么方式存储在索引中。在MySQL中，‘A’（升序）或 NULL（无分类）。
-- Cardinality：索引中唯一值的数目的估计值
-- Sub_part：如果列只是被部分地编入索引，则为被编入索引的字符的数目。如果整列被编入索引，则为NULL
-- Packed：指示关键字如何被压缩。如果没有被压缩，则为NULL
-- Null：如果列含有NULL，则含有YES。如果没有，则该列含有NO
-- Index_type：索引类型（BTREE, FULLTEXT, HASH, RTREE）。

 每个节点可以存放多个数据，每个节点的数据实体处理存放数据外有左右指针指向自己的子节点，也就是说当前节点存放n个数据的话，它最多能有n-1个指针指向自己的子节点。

like与in索引情况

使用到索引的前提条件是 where 条件的这一列本身是有索引的。对于 like 和 in 的使用上：

    like：MySQL 在使用 like 查询的时候只有不以 % 开头的时候，才会使用到索引；

    in：当你 in 中的数据个数 “过多”（比如上万个数据）时，MySQL 将不会使用到索引。可以参考知乎上的一个帖子：https://www.zhihu.com/question/26010353

    另外，在考虑自己的 SQL 语句是否会用到索引时，可以使用 explain 关键字校验下。

 limit offset如何优化

比如：select * from table limit 1700000,10

 limit offset 的实现方法是按顺序查找到对应的位置，并把 limit 之前的数据全部丢弃掉。最终，扫描的数据量是不会变化的。参考这篇：MYSQL分页limit速度太慢优化方法 | OurMySQL

limit10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里。

如果我们之前记录了最大ID呢？

举个例子

   日常分页SQL语句

   select id,name,content from users order by id asc limit 100000,20

   扫描100020行

   如果记录了上次的最大ID

select id,name,content from users where id>100073 order by id asc limit 20

   扫描20行。

   总数据有500万左右

Group by

• Group By 关键字由于涉及到数据的排序，对于数据量特别大的情况，还需要进行外排序，排序的过程会降低 SQL 语句的执行效率。所以，尽量对小数据量进行 Group By 操作；

  ---

  group by的常用优化方案

      效率低的根本原因就是因为数据量大导致的，所以，想要做优化，核心思想就是降低数据量。可以在 group by 之前把需要过滤的数据通过 where 条件给出；给 group by 的相关字段加上索引等等。

• 索引能够加速数据的查询过程，所以，对于经常有 where 条件的字段，可以考虑建立索引；
• 没有实际查询需求的话 主键查询够用了，建立索引本身就占用资源的，能不建就不建，数据量大的话临时加索引还可能锁表影响向线上业务
• 尽量是数据类型占用空间小的字段建立索引，建索引本身就是占用资源的，当还要结合实际查询需求综合考虑，经常需要查询的字段建索引。尽量考虑字段类型使用的空间，对于像 text 这样的字段，就不应该建立索引。

数据库常用的索引规范

    1、表的主键、外键必须有索引；

    2、数据量超过300的表应该有索引；

    3、经常与其他表进行连接的表，在连接字段上应该建立索引；

    4、经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；

    5、索引应该建在选择性高的字段上；

    6、索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；

    7、复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替；

    8、频繁进行数据操作的表，不要建立太多的索引；

    9、删除无用的索引，避免对执行计划造成负面影响。

 3.MySQL 事务

事务隔离级别

什么是事务隔离级别

SQL标准定义了四种隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。

四种隔离级别的说明

四个级别逐渐增强，每个级别解决一个问题。事务级别越高，性能越差，大多数场景 read committed 可以满足需求

• S锁（共享锁）：允许多个事务并发读取数据，但不允许写操作。

• X锁（排他锁）：独占数据，允许写操作，但不允许其他事务读取或写入。

  ---

隔离级别与一致性

四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题 :

• 脏读(Drity Read): 某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。

• 不可重复读(Non-repeatable read): 在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。

• 幻读(Phantom Read): 在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

对应于 MySQL 的四种隔离级别，有可能会产生的问题如下 :

隔离级别的设置

注意：不同的 MySQL 版本，事务隔离级别对应的变量名也是不同的。

-- 查看事务隔离级别 （默认的是 REPEATABLE READ）
mysql> select @@global.transaction_isolation;
+--------------------------------+
| @@global.transaction_isolation |
+--------------------------------+
| REPEATABLE-READ                |
+--------------------------------+

mysql> show variables like '%iso%';
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+

-- 设置事务隔离级别
SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- 更常见的设置事务隔离级别的方法是修改 my.cnf
transaction_isolation = REPEATABLE-READ

QUESTION：企业级开发中通常会把事务隔离级别设置为 Read Committed，你能说出这样做的理由吗 ？（可以对比其他隔离级别的劣势去解释）

默认的：

MySQL 的默认隔离级别是“可重复读”Repeatable Read，但是，我们在工作中几乎都是在使用“读已提交”Read Committed这个隔离级别，那么，其中的原因有以下三点：

    （1）在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多

    （2）在RR隔离级别下，条件列未命中索引会锁表，而在RC隔离级别下，只锁行

    （3）在RC隔离级别下，半一致性读 (semi-consistent) 特性增加了 update 操作的并发性

是考虑到安全和效率上的平衡。另外的三类隔离级别都是有比较大的缺陷，综合来看，提交读是最合理，也是最合适的。

      性能与一致性权衡：选择隔离级别时需要权衡数据一致性和并发性能。如果对数据一致性要求极高，可以选择Serializable；如果对性能要求更高，可以选择Read Committed或Read Uncommitted。