获得徽章 0
#青训营笔记创作活动#
12月16日 day 9
本文讲述了如何通过搜索引擎解决技术问题以及如何阅读英文技术文档。对此,我个人的心得是,硬读,遇到不会的单词查一下,久而久之就会习惯了。
评论
#青训营笔记创作活动#
12月14日 day 8

Kafka->阅读此文前,最好有简单的Kafka上手经验,或许可以更好的理解本文。


消息系统:系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时,Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
存储系统:持久化到磁盘。消息持久化功能和多副本机制
流式处理平台:为每个流行的流式处理框架提供了可靠的数据来源,还提供了一个完整的流式处理类库,比如窗口、连接、变换和聚合等各类操作。

与此同时介绍了Kafka的整体架构,基础概念,消费者与消费组,存储视图和多副本。
展开
评论
#青训营笔记创作活动#
12月13日 day7
http的特点是需要客户端主动请求数据,而websocket可以服务器主动发送数据。
http为了达到类似的效果需要轮询。
websocket开始的时候也是以http为开始,在请求中加入特殊的header,来升级成websocket。
展开
评论
#青训营笔记创作活动#
12月12日 Day 6
DHCP,动态主机配置协议
第三和第四阶段,对于回应的DHCP Server进行回复,并确定一个IP是自己的。
它通过UDP协议实现,因为不知道DHCP Server是谁。
对于广播,UDP只需要发送给`255.255.255.255`即可广播;TCP需要和本地网段所有IP进行连接。
总之,图解TCPIP,去看!
展开
评论
#青训营笔记创作活动#
12月11日 Day 5
SQL优化,即提高SQL的执行效率。通过explain、分段、分页、使用索引,以及一些书写SQL的技巧,来进行SQL优化。而本文的重点则是在如何利用索引。

在不推荐用select *的部分,我想还要补充的一点是:
在使用select *的时候,因为会进行全表扫描,所以会通意向锁来判断是否可以访问数据,因此,全表扫描可能会因为意向锁阻塞,进而造成查询效率变低。
展开
评论
#青训营笔记创作活动#
12月10日 Day4
今日介绍了软件架构演进史,即从单机到集中式到分布式微服务。
同时也介绍了DDD (Domain Driven Design):领域驱动设计。
最大的作用是解耦。
对于微服务,出现较多的关键词也是解耦。
总之今天就是解耦!
展开
评论
#青训营笔记创作活动#
12月9日 Day3

在Innodb存储引擎下, 一个表在保证性能下的存储数据条数,与主键的大小有很大的关联。

数据条数 = (page size / index size) ^ Height (约数)

为此,我想当效率一定的时候(I/O次数一定,层高一定)的时候,因为innodb中page的默认大小是16kb,所以为了让存储条数尽可能大,就要让index size 尽可能小,而我们能决定index中的部分就是key的大小。

为此,我们应当在表设计的时候就要考虑到可用性的前提下,严格限制单条数据的大小,进而在建立索引的时候保证更小的index size。
展开
评论
#青训营笔记创作活动#
12月18日 Day2

阅读

今日主要内容为插件推荐,但是我在文章的头部发现了[项目的链接](github.com)。项目是一个商城相关的项目,其中包括了架构、业务、技术要点和部署几个方面。其中使用了很多中间件,如MySQL、Redis、MongoDB、RabbitMQ等。值得注意的是,里面使用Redis实现缓存,使用MongoDB作为NoSql数据库,OSS实现大对象存储。

这里在技术选型中要考虑的是,不是能用就行,而是要根据实际情况以及业务,选择恰当的DB。
展开
评论
#青训营笔记创作活动#
12月7日 打卡day1
今日学习
限流:拒绝超过系统能力的请求。
根据范围分为单机限流和分布式限流。
根据方式分为计数器、滑动窗口、漏桶、令牌桶。

计数器的问题是,只进行技数,虽然不占用空间,但是当周期性刷新计数的时候会导致上一周期尾部对下一周期头部的影响被无视。
我想解决这个问题的方法是保留每一个在周期内请求的时间戳,统计时间戳数量。
而在文中,解决这一问题的方法是滑动窗口,但滑动窗口精度与各自的数量有关,无法根本解决临界问题。
漏桶算法的看起来是用一个定长队列来处理请求,队列满则拒绝。
令牌桶与漏桶思想类似,但是一个依赖入队时间,一个依赖出队时间。

Redis+Lua的分布式限流,可以以集群为维度进行限流。
展开
评论
个人成就
文章被阅读 64
掘力值 10
收藏集
1
关注标签
41
加入于