获得徽章 0
#青训营笔记创作活动#
1.28 day36
当访问 map 中不存在的 key 时,Go 则会返回元素对应数据类型的零值,比如 nil、’’ 、false 和 0,取值操作总有值返回,故不能通过取出来的值,来判断 key 是不是在 map 中。

检查 key 是否存在可以用 map 直接访问,检查返回的第二个参数即可。
展开
评论
#青训营笔记创作活动#
1.27 day35
TokenLookup:用于设置 token 的获取源,可以选择 header、query、cookie、param,默认为 header:Authorization,同时存在是以左侧一个读取到的优先。当前 demo 将以 header 为数据源,因此在访问 /ping 接口时,需要你将 token 信息存放在 HTTP Header 当中。
展开
评论
#青训营笔记创作活动#
1.23 day34
对于索引为什么不支持数组、链表、队列等结构就不做过多解释了,因为这些结构中的元素都是按序并排存储,如果选择这些结构来实现索引,那走索引依旧等价于走全表,并未带来查询时的效率提升,反而带来了额外的存储开销,这是没有意义的。
展开
评论
#青训营笔记创作活动#
1.21 day33
作为在后端圈开车的多年老司机,是不是经常听到过,“mysql 单表最好不要超过 2000w”,“单表超过 2000w 就要考虑数据迁移了”,“你这个表数据都马上要到 2000w 了,难怪查询速度慢”
展开
评论
#青训营笔记创作活动#
1.20 day32
而我们每一位开发者,作为人类也不例外,无法抵挡时间的流逝,其记忆力会随着时间逐渐推移不断下降,而MySQL中的命令/函数那么多,咱们也并不能完全记住,所以对于前面的那种情况,在实际开发中也属常事,所以本章则会将一些常用的SQL命令/函数全部罗列出来,以后当需要用到时只需回来搜索即可。
展开
评论
#青训营笔记创作活动#
1.19 day31
聊到分布式锁,就不得不先聊到本地锁,如果没有从本地锁到分布式锁这个演进过程或者说是推导过程,我觉得是不合适的,甚至是不完整的。

程序的发展是一步一步递进,知道它是解决什么样的问题,才能更好的理解和学习。
展开
评论
#青训营笔记创作活动#
1.18 day30
跨域问题指的是不同站点之间,使用 ajax 无法相互调用的问题。跨域问题本质是浏览器的一种保护机制,它的初衷是为了保证用户的安全,防止恶意网站窃取数据。 但这个保护机制也带来了新的问题,它的问题是给不同站点之间的正常调用,也带来的阻碍,那怎么解决这个问题呢?接下来我们一起来看。
展开
评论
#青训营笔记创作活动#
1.16 day29
这个流程比较简单,我们很容易想到解决方案,不用工作流也能解决,有一个专门的请假表,当 A 要请假的时候,就往请假表中添加一条记录,这条记录的内容包含了请假的天数、原因、请假的审批人 B 以及一个名为 status 的字段,这个 status 字段表示这个请假申请目前的状态(待审批、已批准还是已拒绝),然后 B 登录系统之后,在请假表中查询到了 A 的请假信息,然后选择批准,此时将 status 字段的值改一下就行了。
展开
评论
#青训营笔记创作活动#
1.15 day28
一般向外暴露的接口,都需要加上一个访问限制,以防止有人恶意刷流量或者爆破,访问限制的做法有很多种,从控制粒度上来看可以分为:全局访问限制和接口访问限制,本文讲的是接口访问的限制。
评论
#青训营笔记创作活动#
1.13 day27
今天是《分库分表 ShardingSphere 原理与实战》系列的开篇文章,之前写过几篇关于分库分表的文章反响都还不错,到现在公众号:程序员小富后台不断的有人留言、咨询分库分表的问题,我也没想到大家对于分库分表的话题会这么感兴趣,可能很多人的工作内容业务量较小很难接触到这方面的技能。这个系列在我脑子里筹划了挺久的,奈何手说啥也不干活,就一直拖到了现在。
展开
评论
#青训营笔记创作活动#
1.11 day26
为了系统性能的提升,我们一般都会将部分数据放入缓存中,加速访问。而DB只承担数据落盘工作。

最简单的理解就是缓存是挡在 DB 前面的一层,为DB遮风挡雨。

架构中最经典的一句话:“没有什么是加一层不能解决的,如果加一层不行,就再加一层”。
展开
评论
#青训营笔记创作活动#
1.10 day25
在服务端开发中,缓存常常被当做系统性能扛压的不二之选。在实施方案上,缓存使用策略虽有一定普适性,却也并非完全绝对,需要结合实际的项目诉求与场景进行综合权衡与考量,进而得出符合自己项目的最佳实践。
展开
评论
#青训营笔记创作活动#
1.9 day24
高并发下如何设计秒杀系统?这是一个高频面试题。这个问题看似简单,但是里面的水很深,它考查的是高并发场景下,从前端到后端多方面的知识。秒杀一般出现在商城的促销活动中,指定了一定数量(比如:10个)的商品(比如:手机),以极低的价格(比如:0.1元),让大量用户参与活动,但只有极少数用户能够购买成功。这类活动商家绝大部分是不赚钱的,说白了是找个噱头宣传自己。虽说秒杀只是一个促销活动,但对技术要求不低。下面给大家总结一下设计秒杀系统需要注意的9个细节。
展开
评论
#青训营笔记创作活动#
1.7 day23
小学上课的时候,都传过小纸条吧?传纸条的时候每个拿到纸条的同学都会忍不住看一眼,毫无隐私可言。

假设班花想对我表白,又不想在传的过程中让别人发现她的情意绵绵。

就会在课间十分钟里告诉我,"每个字母向左移动一位,就是我想对你说的话"。
展开
评论
#青训营笔记创作活动#
1.6 day22
在 Web 应用发展的初期阶段,一个网站的访问量本身就不是很高,直接使用关系型数据库就可以应付绝大部分场景。但是随着互联网时代的崛起,人们对于网站访问速度有着越来越高的要求,直接使用关系型数据库的方案在性能上就出现了瓶颈。因此在客户端与数据层之间就需要一个缓存层来分担请求压力,而 Redis 作为一款优秀的缓存中间件,在企业级架构中占有重要的地位,因此 Redis 也作为面试的必问项。
展开
评论
#青训营笔记创作活动#
1.5 day21
 由于MySQL是作为存储层部署在业务系统的最后端,所有的业务数据最终都要入库落盘,但随着一个项目在线上运行的时间越来越久,数据库中的数据量自然会越来越多,而数据体积出现增长后,当需要从表查询一些数据时,效率会越发低下。在正常情况下,表的查询性能和数据量是成反比的,也就是数据越多,查询越慢。
展开
评论
#青训营笔记创作活动#
1.4 day20
数据库索引,绝对是MySQL的核心功能之一,如果没有索引机制的数据库,那数据的检索效率绝对是令人无法接受的,毕竟没有索引的表数据,就如同一个普通的文本文件存储在磁盘中。在《索引上篇》中,我们对于MySQL提供的索引机制,从引入,到创建、使用、分类、管理....等进行了全面阐述,相信经过上一篇的讲解后,大家对MySQL索引机制建立了系统化的认知,而本篇则会以上篇为基础,对索引机制进一步加深掌握。
展开
评论
#青训营笔记创作活动#
1.3 day19
SQL审核:具有一站式SQL审核面板,可以直观地看到数据库所有变更记录。
SQL建议:能自动检查SQL语句规范,额外提供GitHub Action和API接入方式。
SQL编辑器:可以在线管理及查看数据库表,支持语法的自动提示。
GitOps工作流:支持集成GitHub和GitLab,使用GitOps工作流进行数据库变更。
备份恢复:支持自动备份数据库及恢复数据。
展开
评论
#青训营笔记创作活动#
1.2 day18
如何定位慢SQL呢、我们可以通过慢查询日志来查看慢SQL。默认的情况下呢,MySQL数据库时不开启慢查询日志(slow query log)呢。所以我们需要手动把它打开。
评论
下一页