平时总结笔记

目录

1. HashMap和Hashtable的区别

2. Mysql优化

3. 分布式相关问题

4. 分布式系统的接口幂等性设计

5. 管理分布式session的四种方式

6. Redis相关问题

7. Redis支持哪几种数据类型？1）String（字符串）

9. 缓存穿透

11. Java 对象的序列化、反序列化

12 spring学习笔记

13 SpringCloud笔记

14 b站学学cocos2d   

15 bing 必应搜索技巧

16 一些易错知识点

---

1. HashMap和Hashtable的区别

HashMap 是jdk1.2引进的,继承自AbstractMap类。但二者都实现了Map接口。

Hashtable继承自Dictionary类，Dictionary类是一个已经被废弃的类（见其源码中的注释）。父类都被废弃，自然而然也没人用它的子类Hashtable了。

HashTable键值都不能为null

Hashtable线程安全, 想线程安全的化可以使用ConcurrentHashMap

TreeSet默认自然顺序的有序集合
非线程安全

TreeSet是SortedSet接口的唯一实现类，TreeSet可以确保集合元素处于排序状态。TreeSet支持两种排序方式，自然排序 和定制排序，其中自然排序为默认的排序方式。向TreeSet中加入的应该是同一个类的对象。LinkedHashSet可保证遍历顺序与插入顺序一样

TreeMap
1.无序，不允许重复（无序指元素顺序与添加顺序不一致）
2.TreeMap集合默认会对键进行排序，所以键必须实现自然排序和定制排序中的一种
3.底层使用的数据结构是二叉树

Properties特点：
特有方法      list  将属性列表输出到指定的输出流。
            store   从输入流中读取属性列表（键和元素对）。
            load   以适合使用 load(InputStream) 方法加载到 Properties 表中的格式，将此 Properties 表中的属性列表（键和元素对）写入输出流。

1.    继承于Hashtable，是线程安全的键值对存储结构。

2.    Properties可保存在流中或从流中加载。

3.    只能保存字符串的键值对。

可以使用 Collections. unmodifiableCollection(Collection c) 方法来创建一个只读集合

2. Mysql优化

union all只是合并查询结果，并不会进行去重和排序操作，在没有去重的前提下，使用union all的执行效率要比union高

避免在where中对字段进行null判断, 避免在where中使用!= 和 <> 操作符 还有 or 

select id from t where num=10 or num=20

-- 可以这样查询：

select id from t where num=10 union all select id from t where num=20

5.in 和 not in 也要慎用，否则会导致全表扫描，如：

select id from t where num in(1,2,3)

-- 对于连续的数值，能用 between 就不要用 in 了：

select id from t where

8. 应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行

全表扫描。如：

select id from t where num/2=100

-- 应改为 :

select id from t where num=100*2

9. 应尽量避免在 where 子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表

扫描。如：

select id from t where substring(name,1,3)= ’ abc ’

-- name 以 abc 开头的 id 应改为 :

select id from t where name like ‘ abc% ’

命令行界面（英语**：command-line interface**，缩写]：CLI）

3. 分布式相关问题

如何防止表单重复提交
前端。每次点击后都要等X秒才能点击。
数据库添加唯一索引
服务器返回表单页面时，会先生成一个subToken保存于session或redis，当表单提交时候携带token，如果token一致，则执行后续，并将服务器中的token删除。
如何设计一个秒杀系统
前端。
      在秒杀之前，按钮置灰，并且不给前端真正的请求地址。前端定时请求后端接口，如果到了秒杀时间，则返回给前端真正的地址，前端放开按钮，每次点击后都要等X秒才能点击。

服务器：服务器用nginx做集群、redis也做集群
限流：在秒杀之前，将秒杀数量的令牌存入到redis中，可以用list，每次来请求都去redis中取出令牌，如果获取到说明秒杀成功，然后去访问数据库下单，如果没有获取到，则说明商品卖完了。
消息中间件。如果秒杀数量比较多，例如上万十万，则秒杀成功之后，将成功的请求放入到mq或者kafka中间件中，再从消息队列中获取请求。
服务降级。为了以防万一，还是要做服务熔断降级。
 

4. 分布式系统的接口幂等性设计

唯一id。每次操作，都根据操作和内容生成唯一的id，在执行之前先判断id是否存在，如果不存在则执行后续操作，并且保存到数据库或者redis等。
服务端提供发送token的接口，业务调用接口前先获取token,然后调用业务接口请求时，把token携带过去,务器判断token是否存在redis中，存在表示第一次请求，可以继续执行业务，执行业务完成后，最后需要把redis中的token删除
建去重表。将业务中有唯一标识的字段保存到去重表，如果表中存在，则表示已经处理过了
版本控制。增加版本号，当版本号符合时，才能更新数据
状态控制。例如订单有状态已支付 未支付 支付中 支付失败，当处于未支付的时候才允许修改为支付中等

5. 管理分布式session的四种方式

session复制
        应用服务器开启Web容器的的Session复制功能，在集群中的几台服务器之间同步Session对象。

       方案简单，且从本机读取session也相当快捷，但有非常明显的缺陷：只能使用在集群规模比较小的情况下（企业应用系统，使用人数少，相对比较常见这种模式），当集群规模比较大的时候，集群服务器之间需要大量的通信进行Session的复制，占用服务器和网络的大量资源，系统负担较大。而且由于用户的session信息在每台服务器上都有备份，在大量用户访问下，可能会出现服务器内存都还不够session使用的情况。

session会话保持
       会话保持是利用负载均衡的原地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上。

       这种方案虽然保证了每个用户都能准确的拿到自己的session，而且大量用户访问也不怕，但是这种会话保持不符合系统高可用的需求。这种方案有着致命的缺陷：一旦某台服务器发生宕机，则该服务器上的所有session信息就会不存在，用户请求就会切换到其他服务器，而其他服务器因为没有其对应的session信息导致无法完成相关业务。所以这种方法基本上不会被采纳。

cookie记录
      将session记录在客户端，每次请求服务器的时候将session放在请求中发送给服务器，服务器处理过请求后再将修改过的session返回给客户端

      利用cookie记录session是存在很多缺点：比如cookie的大小存在限制能记录的信息不能超过限制；比如每次请求都要传输cookie影响性能；比如cookie可被修改或者存在破解的可能，导致cookie不能存重要信息，安全系数不够。但是由于cookie简单易用，支持服务器的线性伸缩，而且大部分的session信息相对较小，所以其实很多网站或多或少的都会使用cookie来记录部分不重要的session信息。

session集群
对于session服务器设计简单方式：

　　1.利用分布式缓存