抱大腿第一人
获得徽章 1
- #青训营笔记创作活动#
2月15日 打卡day8
今日学习
通过阅读这篇文章，我知道了分库与分表可以从垂直（纵向）和 水平（横向）两种纬度进行拆分。
垂直拆分：
垂直分库一般来说按照业务和功能的维度进行拆分，将不同业务数据分别放到不同的数据库中，核心理念是专库专用。按业务类型对数据分离，剥离为多个数据库，像订单、支付、会员、积分相关等表放在对应的订单库、支付库、会员库、积分库。不同业务禁止跨库直连，获取对方业务数据一律通过API接口交互，这也是微服务拆分的一个重要依据。垂直分库很大程度上取决于业务的划分，但有时候业务间的划分并不是那么清晰，比如：电商中订单数据的拆分，其他很多业务都依赖于订单数据，有时候界线不是很好划分。垂直分库把一个库的压力分摊到多个库，提升了一些数据库性能，但并没有解决由于单表数据量过大导致的性能问题，所以就需要配合后边的分表来解决。
垂直分表针对业务上字段比较多的大表进行的，一般是把业务宽表中比较独立的字段，或者不常用的字段拆分到单独的数据表中，是一种大表拆小表的模式。数据库它是以行为单位将数据加载到内存中，这样拆分以后核心表大多是访问频率较高的字段，而且字段长度也都较短，因而可以加载更多数据到内存中，减少磁盘IO，增加索引查询的命中率，进一步提升数据库性能。
水平拆分：
水平分库是把同一个表按一定规则拆分到不同的数据库中，每个库可以位于不同的服务器上，以此实现水平扩展，是一种常见的提升数据库性能的方式。这种方案往往能解决单库存储量及性能瓶颈问题，但由于同一个表被分配在不同的数据库中，数据的访问需要额外的路由工作，因此系统的复杂度也被提升了。
水平分表是在同一个数据库内，把一张大数据量的表按一定规则，切分成多个结构完全相同表，而每个表只存原表的一部分数据。水平分表尽管拆分了表，但子表都还是在同一个数据库实例中，只是解决了单一表数据量过大的问题，并没有将拆分后的表分散到不同的机器上，还在竞争同一个物理机的CPU、内存、网络IO等。要想进一步提升性能，就需要将拆分后的表分散到不同的数据库中，达到分布式的效果。展开赞过 评论1 - #青训营笔记创作活动#
2月14日 打卡day7
今日学习
通过阅读这篇文章，我知道了
1.为了系统性能的提升，我们一般都会将部分数据放入缓存中，加速访问，而DB只承担数据落盘工作，最简单的理解就是缓存是挡在 DB 前面的一层，为DB遮风挡雨。
2.读多写少的数据适合放到缓存中。
3.使用缓存后会产生 缓存与数据库双写不一致、缓存雪崩、缓存穿透、缓存并发竞争等问题。展开赞过 评论1 - #青训营笔记创作活动#
2月13日 打卡day6
今日学习
通过阅读这篇文章，我知道了mysql的表锁有元数据锁、意向锁、自增锁、全局锁。
1.元数据锁，也被简称为MDL锁，这是基于表的元数据加锁。
2.意向锁是InnoDB中为了支持多粒度的锁，为了兼容行锁、表锁而设计的。
3.自增锁是专门为了提升自增ID的并发插入性能而设计的。
4.全局锁是基于整个数据库来加锁的，加上全局锁之后，整个数据库只能允许读，不允许做任何写操作，一般全局锁是在对整库做数据备份时使用。展开赞过 评论1 - #青训营笔记创作活动#
2月12日 打卡day5
今日学习
通过阅读这篇文章，我知道了跨域问题的本质是浏览器为了保证用户的一种安全拦截机制，想要解决跨域问题，只需要告诉浏览器“我是自己人，不要拦我”就行。它的常见实现方式有 5 种：通过注解实现局部跨域、通过配置文件实现全局跨域、通过 CorsFilter 对象实现全局跨域、通过 Response 对象实现局部跨域，通过 ResponseBodyAdvice 实现全局跨域。展开赞过 评论1 - #青训营笔记创作活动#
2月11日 打卡day4
今日学习
通过阅读这篇文章，我知道了：
1.HTTPS会对HTTP的URL和Request Body都进行加密，因此直接在filter栏进行过滤http.host == "baidu.com"会一无所获。
2.HTTPS握手的过程中会先通过非对称机密去交换各种信息，其中就包括3个随机数，再通过这三个随机数去生成对称机密的会话秘钥，后续使用这个会话秘钥去进行对称加密通信。如果能获得这三个随机数就能解密HTTPS的加密数据包。
3.这三个随机数，分别是客户端随机数（client random），服务端随机数（server random）以pre_master_key。前两个，是明文，第三个是被服务器公钥加密过的，在客户端侧需要通过SSLKEYLOGFILE去导出。
4.通过设置SSLKEYLOGFILE环境变量，再让curl或chrome请求HTTPS域名，会让它们在调用TLS库的同时导出对应的sslkey文件。这个文件里包含了三列，其中最重要的是第二列的client random信息以及第三列的pre_master_key。第二列client random用于定位，第三列pre_master_key用于解密。展开赞过 评论1 - #青训营笔记创作活动#
2月5日 打卡day3
今日学习
通过阅读本篇文章，我知道了分库分表的原因：
单机数据库的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶颈。当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。一旦数据量朝着千万以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响应速度，缩短查询时间，这时候便需要进行分库分表。展开赞过 评论1 - #青训营笔记创作活动#
2月4日 打卡day2
今日学习
通过阅读本篇文章，我知道了以下几点：
1.使用值为 nil 的 slice、map时，允许对值为 nil 的 slice 添加元素，但对值为 nil 的 map 添加元素，则会造成运行时 panic。
2.检查 key 是否存在可以用 map 直接访问，检查返回的第二个参数即可。
3.string类型的值不能修改，尝试使用索引遍历字符串，来更新字符串中的个别字符，是不允许的。string 类型的值是只读的二进制 byte slice，如果真要修改字符串中的字符，将 string 转为 []byte 修改后，再转为 string 即可。
4.switch 语句中的 case 代码块会默认带上 break，但可以使用 fallthrough 来强制执行下一个 case 代码块。
5.可以直接在处理 HTTP 响应错误的代码块中，直接关闭非 nil 的响应体；手动调用 defer 来关闭响应体。展开赞过 评论1 - #青训营笔记创作活动#
2月3日 打卡day1
今日学习（通过阅读本篇文章，我知道了一下5点：
1.TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景不友好，因此我们需要使用支持全双工的websocket协议。
2.在HTTP1.1中，只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
3.对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用websocket协议。
4.websocket和socket几乎没有任何关系，只是叫法相似。
5.正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作，升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。）展开赞过 评论1