用户2508301637731
获得徽章 1
- #青训营笔记创作活动#
1月30日 打卡day8
redis缺点：数据库容量受到物理内存的限制，不能实现海量数据的高性能读写。相比关系型数据库，不支持复杂逻辑查询，且存储结构相对简单
简单动态字符串优点：获取字符串长度的复杂度较低，减少内存分配次数，兼容C字符串函数，可以重用C语言库的一部分函数
redis高性能原因：完全基于内存 。数据结构简单，操作方便，并且不同数据结构能够应对于不同场景 。采用单线程（网络请求模块使用单线程，其他模块仍用了多线程），避免了不必要的上下文切换和竞争条件，也不存在多进程或多线程切换导致CPU消耗，不需要考虑各种锁的问题。 使用多路I/O复用模型，为非阻塞I/O。
使用Pipeline模式，客户端可以一次性发送多个命令，无需等待服务端返回，这样可以将多次I/O往返的时间缩短为一次，大大减少了网络往返时间，提高了系统性能。
红黑树其实就是平衡树的一种，复杂的定义和规则，最后都是为了保证树的平衡性，解决平衡树的维护起来比较麻烦的问题。如果实在内存中，红黑树比B树的效率更高，但涉及到磁盘操作，B树就更优展开评论点赞 - #青训营笔记创作活动#
1月23日 打卡day7
远程操作或者数据库操作都是比较耗网络、IO资源的，所以尽量不在循环里远程调用、不在循环里操作数据库，能批量一次性查回来尽量不要循环多次去查。
我们经常会遇到一些可变参数，比如用户多少天没登录注销、运营活动，不同节日红包皮肤切换、订单多久没付款就删除等等。对于这些可变的参数，不用该直接写死在代码。优秀的后端，要做配置化处理，你可以把这些可变参数，放到数据库一个配置表里面，也可以放到项目的配置文件或者apollo上。
方法不要写得太复杂，逻辑不要混乱，也不要太长。一个函数不能超过80行。
如果你的需求是在原来接口上修改，尤其这个接口是对外提供服务的话，一定要考虑接口兼容展开评论点赞 - #青训营笔记创作活动#
1月22日 打卡day6
数据传输方式：电路交换、报文交换、分组交换。电路传输方式分配一条专用通信（也就是一条专用的物理通路）。但导致线太多，引出转发和标识。集线器（物理层）：它的每个接口仅仅简单地转发比特（广播），意味着收到即转发（占用）。交换机（数据链路层）：全双工，维护着一张MAC地址与网线端口的对应表。报文交换，报文交换将每个用户发送的数据拆分成多个更小的部分数据，这些更小的数据携带着标识，起始点和目的地。解决了电路交换的占线问题，但是报文交换没有限制大小会有延时问题。分组交换：分组交换的最小信息单位是分组，而报文交换则是一个个报文。两个本质都是存储转发。
路由器跟交换机不同的是，在路由器里维护的是路由表，在路由表中最重要的是目的网络地址（也就是IP）和下一跳地址。。所以从计算机之间的互联到集线器，再从集线器到交换机，而后到路由器。把许多计算机连接在一起形成了计算机网络，而把许多网络连接在一起就构成了互联网展开评论点赞 - #青训营笔记创作活动#
1月20日 打卡day1
TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的websocket协议。
在HTTP1.1里。只要客户端不问，服务端就不答。基于这样的特点，对于登录扫码页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用websocket协议。 websocket和socket几乎没有任何关系，只是叫法相似。
正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作（两次握手），升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。
粘包这个问题的根因是由于开发人员没有正确理解 TCP 面向字节流的数据传输方式，本身并不是 TCP 的问题，是开发者的问题。
TCP 不管发送端要发什么，都基于字节流把数据发到接收端。这个字节流里可能包含上一次想要发的数据的部分信息。接收端根据需要在消息里加上识别消息边界的信息。不加就可能出现粘包问题。
TCP 粘包跟Nagle算法有关系，但关闭 Nagle 算法并不解决粘包问题。
UDP 是基于数据报的传输协议，不会有粘包问题。
IP 层也切片，但是因为不关心消息里有啥，因此有不会有粘包问题。
TCP 发送端可以发 10 次字节流数据，接收端可以分 100 次去取；UDP 发送端发了 10 次数据报，那接收端就要在 10 次收完。
纯裸TCP是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义消息边界。于是就有了各种协议，HTTP和各类RPC协议就是在TCP之上定义的应用层协议展开评论点赞 - #青训营笔记创作活动#
1月19日 打卡day5
电脑插上网线，联网后会通过手动或DHCP协议动态申请一个IP，同时获得子网掩码，路由器地址等信息。
DHCP分为四个阶段，分别是 Discover，Offer， Request和ACK。如果曾经连过这个网，机器会记录你上次使用的IP，再次连接时优先使用原来的那个IP，因此只需要经历第三第四阶段。
DHCP是应用层协议，考虑到需要支持广播（255.255.255.255）功能，底层使用的是UDP协议，而不是TCP协议。
DHCP分配下来的IP是有可能跟某台手动配置的IP地址重复的（手动配置和动态分配一样、多个服务器分配一样的ip）。
DHCP得到IP之后还会发3次无偿ARP通告，在确认没有冲突后开始使用这个IP。展开评论点赞 - 联合索引遇到范围查询(>、<、between、like)就会停止匹配。但注意优化器会自动调整sname, s_code的顺序。因为MySQL创建联合索引的规则是首先会对联合索引的最左边第一个字段排序，在第一个字段的排序基础上，然后在对第二个字段进行排序。所以B=2这种查询条件没有办法利用索引。
8.0后最左缀原则可以通过跳跃扫描的方式打破。当第一列索引的唯一值较少时，即使where条件没有第一列索引，查询的时候也可以用到联合索引。
select * 不会导致索引失效 之前测试发现失效是因为where 查询范围过大 导致MySQL 最优选择全表扫描了 并不是Select * 的问题。但不推荐，因为无用字段增加网络 消耗，尤其是 text 类型的字段。也可以理解为 返回结果集小就会使用索引
like的%在左不走 在右走索引。or两边都得有索引。
IN肯定会走索引，但是当IN的取值范围较大时会导致索引失效，走全表扫描。in 在结果集 大于30%的时候索引失效。Order By会回表的时候优化器选择全表更好
5.6 之后，索引下推就是充分利用 联合索引的字段进过滤 尽量减少需要回表的数据 来增加查询效率。索引下推除了依赖联合索引之外，还不能在子查询下面进行使用。存储函数也不能使用。展开评论点赞 - #青训营笔记创作活动#
1月18日 打卡day4
今天学习了索引失效的一些内容。比如最左匹配原则就是指在联合索引中，如果你的 SQL 语句中用到了联合索引中的最左边的索引，那么这条 SQL 语句就可以利用这个联合索引去进行匹配。评论点赞 - #青训营笔记创作活动#
1月17日 打卡day3
今天看了这篇文章知道了学习服务端需要的一些思维模式。软件的架构模式总的说经历了三个阶段的演进：从单机、集中式到分布式微服务架构评论点赞 - #青训营笔记创作活动#
1月16号 打卡day2
今天学习了mysql相关内容。
知道了b+树保持在三层以内比较好。如果超过三层可以考虑分表。三层b+树存储容量要根据情况进行计算，不可一概而论。树的前两层一页可存N个存储索引数据，第三层存储N*N个叶子结点。一共能存储的记录数为N*N*每一页记录数。展开评论点赞
