记刚开始java实习时的学习日报集合（大杂烩）

1. 索引的选择，尽量选择较大的表创建索引；
索引的选择：（区分度大，尽量少更新）

创建索引的字段一定要选择字段区分度较大的，以为索引本身就要占用空间，所以在数据量大的情况下，索引的空间也越来越大，索引的效果还会较慢，例如在基于性别创建索引；
经常用作过滤器的字段上建立索引，也就是经常用在where语句中作为条件的字段，尽量创建索引；
避免选择大型数据类型的列作为索引；
避免在经常做io操作的字段建立索引，因为io操作字段时，索引也在做io操作，索引正常来说对于读取操作有很大的效果，对于io操作的字段会较慢；

2. 学习了mysql的一些函数：

    RAND()生成0-1的浮点数
    FLOOR()向下取整
    CAST (expression AS data_type)将某种数据类型的表达式显式转换为另一种数据类型，例如以下例子：CAST(FLOOR(RAND()*10000) as

INT)，rand先生成0-1的浮点数，然后乘以10000，再向下取整，相当于生成了0-10000的整数，再通过cast强转；
CONCAT(str1,str2,…) 拼接两个字符串；
substring(目标字符串，开始的索引，截取长度) 字符串截取；

1. 索引相关

解释函数explain或navicat的解释按钮查看语句是否走索引，查看扫描的行数；以及查看执行时间进而推断sql语句是否有优化；
通过实践发现发现，在复合索引中，其中一个子段包含null值的话，该复合索引将会失效；

1：sql优化：

（1）count（）在innodb和MyISAM两个引擎中的区别，在MyISAM引擎的表中，使用count（）查询的速度非常迅速，因为MyISAM会有记录，所以很快；
（2）在使用count（）时，已经是最好的计数方法了，如果有where语句时可以做一些优化，如果一个表有一千万条数据，我们在where语句中条件为id>?,如果个条件id大于一个较为靠后的数，假如id>9999999,则此时扫描的数据很少，所以可以很快的查出数据长度，如果条件是id>10,则此时扫描的数据十分庞大，执行sql很慢，所以，在我们知道id为较小的这种情况下，可以做一下的优化：
SELECT (SELECT count() FROM table) - count(*) FROM table WHERE id
<=10
（3）关于limit的的优化： SELECT a.id,a.cloumn1,a.cloumn2 ,a.cloumn3 ,a.cloumn4 ,a.cloumn5 FROM a LIMIT 1000,10;
在limit方法中，第一个参数是代表着偏移量，数据库会扫描10010条记录的所取字段，然后只返回最后10条记录，可以变为一下这种形式：
SELECT a.id,a.cloumn1,a.cloumn2 ,a.cloumn3 ,a.cloumn4 ,a.cloumn5 FROM
a INNER JOIN (SELECT id FROM a LIMIT 1000,10) AS aa USING(id);
这样在取多个字段的之前先只去一个id字段，减少取出又排除的前面偏移的数据；

1. 分析产生fullgc的可能原因：

（1）：System.gc()方法的调用；
一般是在代码中显式的调用或者有些第三方的依赖包中调用System.gc();方法，有可能但不一定会触发fullgc，所以一般都是建议在jvm层面配置设置禁用System.gc();
（2）：老年代空间不足；
新生代在多次minorgc后，年龄增长，进入老年代，或者创建大对象、大数组，出现空间不足，就会出翔fullgc； （3）：永生区空间不足；
永生区一般存放常量，静态变量，类，方法这些，一般由于系统增长，有可能会发生这些问题，可以通过配置jvm解决； （4）：统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间； （5）：堆中分配很大的对象； （6）：CMS
GC时出现promotion failed和concurrent mode failure；
其中主要比较关注（2）、（5）两个点，两个点有点联系，因为直接生成大对象的话或直接进入老年代，如果太大，超过老年代的剩余空间，就会触发fullgc；我们在日常开发中，应尽量避免生成过大的大对象，让对象在尽量在monirgc时就被回收，数据较大时，尽量不要用大对象，让分成多个对象，让其在新生代多存活一段使时间，而不进老年代，因为majorgc比monigc慢大约十倍，如果majorgc之后空间仍然不足，就会触发fullgc，如果还是不行就会抛出oom异常；

一个接口要是多个实现类怎么注入，一个类实现了多个接口，又是怎么注入，ioc容器怎么识别他们

经过相关查找和小实验，当一个接口有多个实现类的时候，实现类必须在@service注解中标注名称，可以通过@Autowired和@Qualifier配合注入，或者使用Resource注解注入。
一个类实现多个接口的时候，在我们使用@Autowired注解时使用的哪个接口，就只能使用那个接口的方法；

SpringMVC的核心类和注解：

SpringMVC核心类：DispatcherServlet；DispatcherSevlet负责将请求分发，所有的请求都有经过它来统一分发；
SpringMVC常用注解：
@Controller 用于标记在一个类上，使用它标记的类就是一个SpringMVC Controller 对象。分发处理器将会扫描使用了该注解的类的方法，并检测该方法是否使用了
@RequestMapping注解为控制器指定可以处理哪些URL请求；@Controller
只是定义了一个控制器类，而使用@RequestMapping 注解的方法才是真正处理请求的处理器。 @RequestParam
映射请求参数， @PathParam 和
@QueryParam，两个注解都是取路径的，但是方式不同。主要是看你怎么传入的路径。@QueryParam 主要通过键值对这样取 如
a=1，@PathParam 主要通过路径映射取
@Resource和@Autowired都是做bean的注入时使用，@Autowired为Spring提供的注解，只按照ByType注入。@Resource默认按照ByName自动注入，
@Component相当于通用的注解，当不知道一些类归到哪个层时使用，但是不建议。
@Repository用于注解dao层，在daoImpl类上面注解。
@RequestParam主要用于在SpringMVC后台控制层获取参数。

SpringMVC的参数绑定：

前端传来的统一是string类型，springmvc会自动做转换，自动识别通过参数名等转换成int，String等类型，但需要其参数名和前端的传来参数名一样，不一样时可以使用@RequestParam(“前端传来的名”)使用，绑定在指定的参数上，SpringMVC支持基本数据类型，也支持对象类型；当使用@RequestBody注解时，只支持POST类型的请求；

定义时是varchar，存储在数据库却是纯数字，所以mybatis会当成整形转换，我们实体类用的是String类型，所以转换错误

后台的core模块总是会报错，取出控制台打印的SQL到客户端运行也没有问题，编辑工具控制台报的确是类型封装时的转换错误，最后请教组长，组长发现了原来指定的那几条数据的ID，虽然定义时是varchar，存储在数据库却是纯数字，所以mybatis会当成整形转换，我们实体类用的是String类型，所以转换错误

springMVC的JSON数据交互，和RESTful风格的支持；

JSON数据是以“{”开头，“}”结尾的键值对出现的数据交换格式，常用于前后端分离的场景的交互使用，相对于传统的XML的数据，有着高性能、占用空间小的优势，适用于网络传输；
SpringMVC中@RequestBody注解可以用于读取JSON内容，使用@ResponseBody注解作用于Controller方法上，将返回值转换成JSON发送给前端。
RESTful不是具体的一种技术，可以说是一种设计风格，就是吧参数变成请求路径的一种风格，SpringMVC可以使用@GetMapping@PostMapping@PutMapping@DeleteMapping@PatchMapping等的指定请求方法的请求，需要使用HiddenHttpMethodFilter类配置过滤器。

SpringMVC拦截器

SpringMVC拦截器相当于servlet
过滤器，但又有些区别，过滤器只能做请求之前的预处理，拦截器可以做预处理和后处理，过滤器可以用在任何javaWeb项目中，而SpringMVC拦截器只能用在SprinMVC项目中，拦截器其实也是AOP思想的一种实现，springMVC拦截器的实现一般有两种方式：
第一种方式是要定义的Interceptor类要实现了HandlerInterceptor 接口；
第二种方式是继承实现了HandlerInterceptor接口的类，实现了HandlerInterceptor接口的抽象类HandlerInterceptorAdapter；

Linux

tail -f filename 会把 filename 文件里的最尾部的内容显示在屏幕上，并且不断刷新，只要 filename
更新就可以看到最新的文件内容； 例如：tail -n 5 core.log实时显示core.log文件的最后五行，grep ‘初始化’
core.log 查询文件包含’初始化’的关键字，在vi编辑器下使用/命令查找关键字；

SpringMVC的文件上传和下载：

Springmvc支持文件的上传和下载，文件的上传时，需要定义一个form表单设置method属性为post，设置enctype属性为multipart/form-data，还有一个文件上传的入口input标签，type=“file”,多文件上传时可以加一个multiple=“multipe”，浏览器会以二进制的字节流，springmvc为文件上传提供直接的支持，可以通过MultipartResolver接口的实现类CommonsMultipartResolver完成文件上传，配置MultipartResolver额bean，可以在配置bean时配置编码格式、上传最大的大小;文件的下载可以使用Springmvc的responseEntity对象。

mybatis常用动态sql标签

<if>,<choose>,<when>,<otherwise>,<where>,<set>,<trim>,<foreach>,<bind>；

mybatis的关系映射：

在数据库存在多表之间存在着三种关联关系，分别为一对一、一对多和多对多，在一对一结果映射时，使用resultType更加简单方便，如果有特殊要求时，需要使用resultMap进行映射，比如：查询列表，然后在点击列表中的查看明细按钮，这个时候就需要使用resultMap进行结果映射。而resultType更适应于查询明细信息。

springmvc自动做转换

前端传来的统一是string类型，springmvc会自动做转换，自动识别通过参数名等转换成int，String等类型，但需要其参数名和前端的传来参数名一样，不一样时可以使用@RequestParam(“前端传来的名”)使用，绑定在指定的参数上，SpringMVC支持基本数据类型，也支持对象类型；当使用@RequestBody注解时，只支持POST类型的请求；

cap原理：

C：代表着"一致性"，是写操作之后的读取时必须返回该值；
A：代表着"可用性"，意思是只要收到客户端的请求，服务器就必须给出响应；
P：代表着“分区容错性”，一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。
当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。
提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。
然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题
数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低

token

token的作用类似于session，适用于部分场景session无法或较难解决的问题，相比于session的优势是，token不存储在服务器，所以节省了服务器的内存，而且在集群的服务器就不需要考虑共享session的问题；token的实现原理是首次客户端向服务器发送校验信息，通过校验后，服务器做一个签名，生成类似身份验证的字符串，发送给客户端，往后的客户端与服务端通讯就携带此token，作为身份校验。浏览器端一般通过cookie存储token，所以服务器无需保存会话信息，在集群的服务器中，每次访问到不同的机器时，只要携带的token通过验证就可以，无需解决以前的多服务器共享session的问题；

redis五大数据类型

String 数据结构是简单的key-value类型，value其实不仅是String，也可以是数字;
hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象;
List 就是链表，Redis list的实现为一个双向链表，即可以支持反向查找和遍历;
Set 就是一个集合，集合的概念就是一堆不重复值的组合,set是通过hashtable实现的,set 的内部实现是一个 value永远为null的HashMap;
Zset的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序;

redis的五大数据类型的基本操作：

String
　　1 SET key value　　设置指定 key 的值
　　2 GET key　　获取指定 key 的值。
　　3 GETRANGE key start end　　返回 key 中字符串值的子字符。（下标从0开始，GETRANGE key 0 -1表示返回整个字符串）
list
       1 BLPOP key1 [key2 ] timeout　　移出并获取列表的第一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
　　2 BRPOP key1 [key2 ] timeout　　移出并获取列表的最后一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
　　3 BRPOPLPUSH source destination timeout　　从列表中弹出一个值，将弹出的元素插入到另外一个列表中并返回它；如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
　　4 LINDEX key index　　通过索引获取列表中的元素
　　5 LINSERT key BEFORE|AFTER pivot value　　在列表的元素前或者后插入元素
Hash-哈希　　
　　1 HDEL key field2 [field2]　　删除一个或多个哈希字段
　　2 HEXISTS key field　　判断一个哈希字段存在与否
　　3 HGET key field　　获取存储在指定的键散列字段的值
Set-集合
　　1 SADD key member1 [member2]　　向集合添加一个或多个成员
　　2 SCARD key　　获取集合的成员数
　　3 SDIFF key1 [key2]　　返回给定所有集合的差集
Zset-有序集合
　　1 ZADD key score1 member1 [score2 member2]　　向有序集合添加一个或多个成员，或者更新已存在成员的分数
　　2 ZCARD key　　获取有序集合的成员数
　　3 ZCOUNT key min max　　计算在有序集合中指定区间分数的成员数

xml中编写时<=的符号时，idea会提示可能会被当成标签，而无法实现<=的逻辑；应该使用<的转义字符来实现<符号的逻辑；类似的还有一些特殊的符号，需要进行转义，以下是相关常见特殊字符及相应的转义字符；

redis的RDB持久化：

RDB 就是 Snapshot 快照存储，是默认的持久化方式。它按照一定的策略周期性地将数据存储到磁盘，生成名为 dump.rdb
的文件，RDB的执行周期可以通过配置文件中的save来配置。在指定的时间间隔内，执行指定次数的写操作，会将内存中的数据写入到磁盘中。即在指定目录下生成一个
dump.rdb 文件。Redis 重启会通过加载 dump.rdb
文件恢复数据。实际操作过程是复制一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储，使用RDB持久化的方式适用于对于一致性要求不是那么高的场景；

redis持久化之AOF （append only file）:

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作,redis默认时不开启AOF持久化，若要开启，需要在配置文件将appendonly赋值为yes；当同时又rdb文件和aof文件时，恢复时aof的优先级更高；若是aof文件中有语法错误时，可以使用Redis-check-aof
–fix命令进行修复；

redis配置文件的基本配置：

daemonize no :默认情况下，redis不是在后台运行的，如果需要在后台运行，把该项的值更改为yes
pidfile /xxx/xxx/redis.pid:当运行多个redis服务时，需要指定不同的pid文件和端口
port 6379:指定redis运行的端口，默认是6379
timeout:设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令，那么关闭该连接, 0是关闭此设置
loglevel: 指定日志记录级别,Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
logfile /xxx/redis.log:配置log文件地址
databases 16:可用数据库数,默认值为16，默认数据库为0，数据库范围在0-（database-1）之间
save:指出在多长时间内，有多少次更新操作，就将数据同步到数据文件rdb;
rdbcompression yes:存储至本地数据库时（持久化到rdb文件）是否压缩数据，默认为yes
dbfilename dump.rdb：本地持久化数据库文件名，默认值为dump.rdb

Redis的消息发布订阅的简单认识：

SUBSCRIBE：订阅命令，一次可以直接订阅多个；
PUBLISH：消息发布命令；
PSUBSCRIBE：订阅多个主题的消息，以通配符的方式匹配；
PUBLISH：接收消息的命令；

redis主从复制：

配置多台Redis服务器，以主机和备机的身份分开。主机数据更新后，根据配置和策略，自动同步到备机的master/salver机制，Master以写为主，Slave以读为主，二者之间自动同步数据。redis的主从复制，读写分离；主从建立可以临时建立，在从服务器使用SLAVEOF
ip:port命令，就可以认指定ip为主redis服务器；要想永久配置则需要在配置文件配置role:slave;

redis的哨兵模式：

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

BigDecimal

在一般的科学计算中，我们可以使用double和float来计算相关的浮点数，但是在商业中涉及金额的计算时，我们会使用BigDecimal包装类型用于这种对于精度要求较高的计算；不同于常见的数字类型的计算，BigDecimal使用不能直接使用±*/等运算符运算，要使用BIgDecimal封装的相关方法计算，
add(BigDecimal value); //加法 subtract(BigDecimal value); //减法
multiply(BigDecimal value); //乘法 divide(BigDecimal value);//除法
其中最为应该注意的是divide(BigDecimal value)除法，当使用divide(BigDecimal
value)方法进行除法时当不整除，出现无限循环小数时就会抛异常；所以一般会明确精度，甚至设置舍入模式，有8中舍入模式： public
final static int ROUND_UP = 0; public final static int
ROUND_DOWN = 1; public final static int ROUND_CEILING =
2; public final static int ROUND_FLOOR = 3; public final static
int ROUND_HALF_UP = 4; public final static int ROUND_HALF_DOWN =
5; public final static int ROUND_HALF_EVEN = 6; public final static
int ROUND_UNNECESSARY = 7;

MQ的作用：

1．
异步。异步就是MQ的第一个能力。可以将一些非核心流程，如日志，短信，邮件等，通过MQ的方式异步去处理。这样做的好处是缩短主流程的响应时间，提升用户体验。
2．
解耦。假设现在，日志不光要插入到数据库里，还要在硬盘中增加文件类型的日志，同时，一些关键日志还要通过邮件的方式发送给指定的人。直接从MQ中获取消息并处理即可。这就是解耦，它的好处是提高系统灵活性，扩展性。
3．
消峰。这个其实也很好理解，因为MQ的本质就是业务的排队。所以，面对突然到来的高并发，MQ也可以不用慌忙，先排好队，不要着急，一个一个来。消峰的好处就是避免高并发压垮系统的关键组件，如某个核心服务或数据库等。
异步，解耦，消峰，MQ的三大主要应用场景。

Rocketmq各角色的学习

Producer：消息的发送者；举例：发信者
Consumer：消息接收者；举例：收信者
Broker：暂存和传输消息；举例：邮局
NameServer：管理Broker；举例：各个邮局的管理机构
Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；一个消息的接收者可以订阅一个或者多个Topic消息
Message Queue：相当于是Topic的分区；用于并行发送和接收消息