13 http协议相关、服务器给客户端发送消息、websocket、悲观锁乐观锁

一、讲述http协议详情、协议版本、请求头？

协议特点

• hyper text transfer protocol 超文本传输协议
• 数据是明文传输的，无状态、无连接
• 基于请求响应，应用层的协议

请求数据格式

• 请求首行：请求方法
• 请求头：一对键值对
• 请求体：主要携带敏感数据

响应数据格式

• 响应首行：响应状态码
• 响应头：一对键值对
• 响应体：给用户展示的数据

协议版本

• 0.9版本：最古老的版本仅支持get请求方法且仅支持HTML格式的资源
• 1.0版本：TCP链接不能重复用，不支持connection：keep-alve参数添加
• 1.1版本：TCP链接默认不关闭，引入了connection：keep-alive参数
• 2.0版本：增加双工模式、可以并发多个请求、可以多路服用
• 3.0版本：只是概念性的东西，目前没有实际使用
  常见的请求头
• cookie
• refer
• user-agent
• connection
• X-Forwarded-For
• 自定制token

GET请求和POST请求有什么区别？

• POST请求携带数据在body中所以更安全，不会被缓存用于修改，通常用来修改或写入数据
• GET请求携带数据在地址栏中，一般请求的是静态资源且会有缓存 POST请求比GET请求慢一些

二、如何实现服务器给客户端发消息，websocket是什么？用过吗？

如何实现服务器给客户端发送信息？

• 利用websocket协议可以实现，目前效率最高

websocket是什么？

• websocket是一种通信协议，可以实现服务器主动给客户端发送信息
• websocket使得客户端和服务器之间的数据交换变得更加简单允许服务端主动向客户端推送数据

用过吗？有哪些场景可以使用？

• 在线聊天室
• 股票行情分析
• 实时反馈服务器基本信息

三、悲观锁乐观锁是什么？如何实现？

无论是悲观锁还是乐观锁都是关于锁机制的一种思想，跟编程语言、数据库、框架都没有关系。都是为了避免并发安全问题

• 乐观锁：假设不会出现冲突，没有锁但是有比较机制，事务提交之前先跟原来的数据比较，如果比较结果不一样就事务不能提交
• 悲观锁：假设每个事物都会出现冲突，所以对数据进行操作前先获得锁才能继续操作，操作完毕之后才释放锁，即并行变成穿串行，互斥锁是最典型的悲观锁

在Redis中通过pipline管道模拟事物的方式可以实现乐观锁

watch age  # 监听数据变化
multi  # 开启事务
decr age  # 事务里面执行的代码
exec  # 提交事务

乐观锁和悲观锁的应用场景
并发量：
响应速度：
冲突频率：
重试代价：
读多写少：
并发量:如果并发量不大，可以使用悲观锁解决并发问题;但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题，建议乐观锁
响应速度:如果需要非常高的响应速度，建议采用乐观锁方案，成功就执行，不成功就失败，不需要等待其他并发去释放锁。乐观锁并未真正加锁，效率高
冲突频率:如果冲突频率非常高，建议采用悲观锁，保证成功率。冲突频率大，选择乐观锁会需要多次重试才能成功，代价比较大
重试代价:如果重试代价大，建议采用悲观锁。悲观锁依赖数据库锁，效率低。更新失败的概率比较低读多写少: 乐观锁适用于读多写少的应用场景，这样可以提高并发粒度