用户4461188015932
获得徽章 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 字节后端训练营#
展开评论点赞