获得徽章 0
Git 作为一个强大的代码管理工具,一直以来都是各大公司的首选,尤其是全球最大的开源社区 GitHub 将 Git用到了炉火纯青的地步。

在我们日常工作中,协同开发是最高效的一种方式,尤其是比较大的需求点以及功能,甚至是新项目的开发。这种情况下,Git 的使用无可避免的也会出现一些问题。

首先,项目开发容易存在的问题:

Git 分支管理分支混乱;

工作流混乱;

没有有效的进行 Review 代码;

混乱的代码管理,对线上功能埋下了巨大隐患,而稳定性的前提就是要对代码进行有效管理,如何制定最符合团队风格的工作流成为了我们工作的重中之重!

#青训营 x 字节后端训练营#
展开
评论
Hadoop是Apache软件基金会下一个开源分布式计算平台,以hdfs(Hadoop Distributed File System)、MapReduce(Hadoop2.0加入了YARN,Yarn是资源调度框架,能够细粒度的管理和调度任务,还能够支持其他的计算框架,比如spark)为核心的Hadoop为用户提供了系统底层细节透明的分布式基础架构。hdfs的高容错性、高伸缩性、高效性等优点让用户可以将Hadoop部署在低廉的硬件上,形成分布式系统。目前最新版本已经是3.x了,
#青训营 x 字节后端训练营#
展开
评论
我们在日常开发中,为了提高数据响应速度,可能会将一些热点数据保存在缓存中,这样就不用每次都去数据库中查询了,可以有效提高服务端的响应速度,那么目前我们最常使用的缓存就是 Redis 了。
用 Redis 做缓存,并不是一说缓存就是 Redis,还是要结合业务的具体情况,我们可以根据不同业务对数据要求的实时性不同,将数据分为三级,以电商项目为例:
第 1 级:订单数据和支付流水数据:这两块数据对实时性和精确性要求很高,所以一般是不需要添加缓存的,直接操作数据库即可。
第 2 级:用户相关数据:这些数据和用户相关,具有读多写少的特征,所以我们使用 redis 进行缓存。
第 3 级:支付配置信息:这些数据和用户无关,具有数据量小,频繁读,几乎不修改的特征,所以我们使用本地内存进行缓存。

选中合适的数据存入 Redis 之后,接下来,每当要读取数据的时候,就先去 Redis 中看看有没有,如果有就直接返回;如果没有,则去数据库中读取,并且将从数据库中读取到的数据缓存到 Redis 中,大致上就是这样一个流程,读取数据的这个流程实际上是比较清晰也比较简单的,没啥好说的。
然而,当数据存入缓存之后,如果需要更新的话,往往会来带另外的问题:

当有数据需要更新的时候,先更新缓存还是先更新数据库?如何确保更新缓存和更新数据库这两个操作的原子性?
更新缓存的时候该怎么更新?修改还是删除?

怎么办?正常来说,我们有四种方案:

先更新缓存,再更新数据库。
先更新数据库,再更新缓存。
先淘汰缓存,再更新数据库。
先更新数据库,再淘汰缓存。
#青训营 x 字节后端训练营#
展开
评论
Pinia 号称下一代的 Vuex。

经过初步体验,发现相比于 Vuex,Pinia 确实有了很大进步,最明显的就是删减了复杂的概念,简化了数据流转的过程,现在只剩下了 store、state、getters、actions 这四个核心概念。

接下来使用一个用户登录的案例,来学习 Pinia 的使用。

案例概述

需要用到:

vite:创建和管理 vue 项目

pinia:状态管理

axios:网络请求

vite-plugin-mock:提供登录的 mock 接口

pinia-plugin-persistedstate:状态持久化插件

我们会先 mock 一个简单的登录接口,然后介绍使用 Pinia 的基本流程,最后在组件中使用 Pinia,完成整个流程。
#青训营 x 字节后端训练营#
展开
评论
动态规划(Dynamic Programming),因此常用 DP 指代动态规划。动态规划,首先我们得清楚,它的概念是啥,它能解决什么问题,维基百科对它的解释👇

动态规划在寻找有很多重叠子问题的情况的最佳解时有效。它将问题重新组合成子问题,为了避免多次解决这些子问题,它们的结果都逐渐被计算并被储存,从简单的问题直到整个问题都被解决。因此,动态规划储存递归时的结果,因而不会在解决同样的问题时花费时间。

动态规划只能应用于有最佳子结构的问题。最佳子结构的意思是局部最佳解能决定全域最佳解(对有些问题这个要求并不能完全满足,故有时需要引入一定的近似)。简单地说,问题能够分解成子问题来解决。

我稍微总结一下👇

将一个大的问题拆分成一个个子问题,我们把它称之为子结构。

每个最优解,也就是最优值均由[这些小规模子问题]推到而来。

更重要的就是利用历史记录,来避免我们重复的计算。
#青训营 x 字节后端训练营#
展开
评论
分布式系统前身就是集中式的系统,他有一个中心化的节点,可能是一台或者多台机器组成,所有的数据存储、计算都在主机上完成。集中式系统的优点:部署简单,可靠性高,数据一致性强等等。

随着客户量和交易量的不断增长,建立在大型主机上的集中式架构系统性能越来越吃紧,这个时候能采用的手段就是提升硬件配置,比如加内存、扩展磁盘、升级 CPU 等等。这样的扩展方式叫做横向扩展(scale up)

但是硬件并不能无条件的扩展,在扩展到某个点以后,扩展硬件对系统的提升将会非常有限。而且系统硬件的价格也随着水涨船高。

#青训营 x 字节后端训练营#
展开
评论
一种常见的基础数据结构,也是一种线性表,但是并不会按线性表的顺序存储数据,而是在每一个节点里存到下一个节点的指针(Pointer)。

链表在插入的时候可以达到 O(1) 的复杂度,比另一种线性表 —— 顺序表快得多,但是查找一个节点或者访问特定编号的节点则需要 O(n)的时间,而顺序表相应的时间复杂度分别是 O(log n) 和 O(1)。

优缺点:



使用链表结构可以克服数组链表需要预先知道数据大小的缺点,链表结构可以充分利用计算机内存空间,实现灵活的内存动态管理。但是链表失去了数组随机读取的优点,同时链表由于增加了结点的指针域,空间开销比较大。



「链表允许插入和移除表上任意位置上的节点,但是不允许随机存取。」
#青训营 x 字节后端训练营#

展开
评论
一句话,对分治法概括它的话

将原问题划分成n个规模较小而结构与原问题相似的子问题,递归去解决这些子问题,然后依次再合并其结果,最后得到原问题的解。

那么具体的来说,我们似乎可以分成三个步骤👇

分解:将要解决的问题划分成若干规模较小的同类问题。

解决:当子问题划分得足够小时,用较简单的方法解决。

合并:按原问题的要求,将子问题的解逐层合并构成原问题的解。

其实思想还是不变的,将一个难以直接解决的大问题,分割成一些小规模的相同问题,以便各个击破,分而治之。
#青训营 x 字节后端训练营#

展开
评论
http0.9只是一个简单的协议,只有一个GET方法,没有首部,目标用来获取HTML。

HTTP1.0协议大量内容:首部,响应码,重定向,错误,条件请求,内容编码等。

http0.9流程:

客户端,构建请求,通过DNS查询IP地址,三次握手建立TCP连接,客户端发起请求,服务器响应,四次挥手,断开TCP连接。(与服务器只有一个来回)

http1.0流程:

客户端,构建请求,通过DNS查询IP地址,三次握手建立TCP连接,客户端发起请求,服务器响应,四次挥手,断开TCP连接。(与服务器有两个来回)
#青训营 x 字节后端训练营#

展开
评论
Viper是适用于Go应用程序的完整配置解决方案。它被设计用于在应用程序中工作,并且可以处理所有类型的配置需求和格式。它支持以下特性:

设置默认值

从JSON、TOML、YAML、HCL、envfile和Java properties格式的配置文件读取配置信息

实时监控和重新读取配置文件(可选)

从环境变量中读取

从远程配置系统(etcd或Consul)读取并监控配置变化

从命令行参数读取配置

从buffer读取配置

显式配置值
#青训营 x 字节后端训练营#

展开
评论
HTTP 是明文传输,容易受到中间人攻击,不安全。
HTTPS 语义仍然是 HTTP,只不过是在 HTTP 协议栈中 http 与 tcp 之间插入安全层 SSL/TSL。
安全层采用对称加密的方式加密传输数据和非对称加密的方式来传输对称密钥,解决 http 数据没有加密、无法验证身份、数据容易纂改三个核心问题。

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

其中验证身份问题是通过验证服务器的证书来实现的,证书是第三方组织(CA 证书签发机构)使用数字签名技术管理的,包括创建证书、存储证书、更新证书、撤销证书。

浏览器连接至一个 HTTPS 网站,服务器发送的不仅仅只是服务器实体证书,而是一个证书链,但不包含根证书,根证书会被内嵌在 Windows, Linux, macOS, Android, iOS 这些操作系统里。
#青训营 x 字节后端训练营#
展开
评论
HTTP/HTTPS 是应用层使用的通信协议,常见的应用层体系结构是客户端-服务器体系。
对运行在不同端系统上的客户端程序和服务端程序是如何互相通信的么?实际上,在操作系统上的术语中,进行通信的实际上是进程而不是程序,一个进程可以被认为是运行在端系统中的一个程序。
在 web 应用程序中,一个客户浏览器进程与一台服务器进程进行会话交换报文。
浏览器进程需要知道接收进程的主机地址,以及定义在目的主机中的接收进程的标识符,也就是目的端口。
多数应用程序由通信进程对组成,每对中的两个进程互相发送报文。进程通过一个称为套接字的软件接口向网络发送报文和从网络接收报文。
进程可以类比一座房子,而它的套接字可以是它的门,套接字是应用层与运输层之间的端口。
#青训营 x 字节后端训练营#
展开
评论
用 Redis 做缓存,并不是一说缓存就是 Redis,还是要结合业务的具体情况,我们可以根据不同业务对数据要求的实时性不同,将数据分为三级,以电商项目为例:

第 1 级:订单数据和支付流水数据:这两块数据对实时性和精确性要求很高,所以一般是不需要添加缓存的,直接操作数据库即可。

第 2 级:用户相关数据:这些数据和用户相关,具有读多写少的特征,所以我们使用 redis 进行缓存。

第 3 级:支付配置信息:这些数据和用户无关,具有数据量小,频繁读,几乎不修改的特征,所以我们使用本地内存进行缓存。

选中合适的数据存入 Redis 之后,接下来,每当要读取数据的时候,就先去 Redis 中看看有没有,如果有就直接返回;如果没有,则去数据库中读取,并且将从数据库中读取到的数据缓存到 Redis 中,大致上就是这样一个流程,读取数据的这个流程实际上是比较清晰也比较简单的,没啥好说的。
#青训营 x 字节后端训练营#

展开
评论
说到事务,就不得不提一下事务著名的四大特性。

原子性 原子性要求,事务是一个不可分割的执行单元,事务中的所有操作要么全都执行,要么全都不执行。

一致性 一致性要求,事务在开始前和结束后,数据库的完整性约束没有被破坏。

隔离性 事务的执行是相互独立的,它们不会相互干扰,一个事务不会看到另一个正在运行过程中的事务的数据。

持久性 持久性要求,一个事务完成之后,事务的执行结果必须是持久化保存的。即使数据库发生崩溃,在数据库恢复后事务提交的结果仍然不会丢失。

注意:事务只能保证数据库的高可靠性,即数据库本身发生问题后,事务提交后的数据仍然能恢复;而如果不是数据库本身的故障,如硬盘损坏了,那么事务提交的数据可能就丢失了。这属于『高可用性』的范畴。因此,事务只能保证数据库的『高可靠性』,而『高可用性』需要整个系统共同配合实现。
#青训营 x 字节后端训练营#
展开
评论
http1.1中浏览器再也不用为每个请求重新发起TCP连接了,增加内容有:缓存相关首部的扩展,OPTIONS方法,Upgrade首部,Range请求,压缩和传输编码,管道化等。但还是满足不了现在的web发展需求,so,就有了http.2版本。
http2解决了(管道化特性可以让客户端一次发送所有的请求,但是有些问题阻碍了管道化的发展,即是某个请求花了很长时间,那么队头阻塞会影响其他请求。)http中的队头阻塞问题。
#青训营 x 字节后端训练营#
展开
评论
构建高可用、高性能的通信服务,通常采用服务注册与发现、负载均衡和容错处理等机制实现。根据负载均衡实现所在的位置不同,通常可分为以下三种解决方案:

1、集中式LB(Proxy Model)

2、进程内LB(Balancing-aware Client)

3、独立 LB 进程(External Load Balancing Service)
gRPC 默认使用 protocol buffers,这是 Google 开源的一套成熟的结构数据序列化机制(当然也可以使用其他数据格式如 JSON)。其客户端提供Objective-C、Java接口,服务器侧则有Java、Golang、C++等接口,从而为移动端(iOS/Androi)到服务器端通讯提供了一种解决方案。
#青训营 x 字节后端训练营#
展开
评论
组合模式的概念:
一个具有层级关系的对象由一系列拥有父子关系的对象通过树形结构组成。
并发组合模式的概念:
一个具有层级关系的对象由一系列拥有父子关系的对象通过树形结构组成,子对象即可被串行执行,也可被并发执行
并发组合模式的优势:
原本串行的业务(存在阻塞的部分,比如网络IO等)可以被并发执行,利用多核优势提升性
相对于「组合模式」,引入并发之后需要着重关注如下几点:
并发子组件需要设置超时时间:防止子组件执行时间过长,解决方案关键字context.WithTimeout
区分普通组件和并发组件:合成复用基础组件,封装为并发基础组件
拥有并发子组件的父组件需要等待并发子组件执行完毕(包含超时),解决方案关键字sync.WaitGroup
并发子组件执行自身业务逻辑是需检测超时:防止子组件内部执行业务逻辑时间过长,解决方案关键字select和<-ctx.Done() #青训营 x 字节后端训练营#
展开
评论
下一页
个人成就
文章被阅读 547
掘力值 73
收藏集
0
关注标签
0
加入于