- 博客(398)
- 收藏
- 关注
RSS订阅原创 day5 分布式节点
本文是`7天用Go从零实现分布式缓存GeeCache`的第五篇。- 注册节点(`Register Peers`)，借助一致性哈希算法选择节点。- 实现 `HTTP` 客户端，与远程节点的服务端通信，代码约`90`行
2024-07-20 23:00:42
976
原创 day4一致性哈希
本文是`7天用Go从零实现分布式缓存GeeCache`的第四篇。- 一致性哈希(`consistent hashing`)的原理以及为什么要使用一致性哈希。- 实现一致性哈希代码，添加相应的测试用例，代码约`60`行
2024-07-20 20:14:14
615
原创 day3 HTTP 服务端
本文是7天用Go从零实现分布式缓存GeeCache的第三篇。介绍如何使用 Go 语言标准库 http 搭建 HTTP Server并实现 main 函数启动 HTTP Server 测试 API，代码约60行
2024-07-20 18:12:24
848
原创 day2 单机并发缓存
本文是`7天用Go从零实现分布式缓存GeeCache`的第二篇。- 介绍 `sync.Mutex` 互斥锁的使用，并实现 `LRU` 缓存的并发控制。- 实现 `GeeCache` 核心数据结构 `Group`，缓存不存在时，调用回调函数获取源数据，代码约`150`行
2024-07-20 14:37:54
1004
原创 day1 LRU 缓存淘汰策略
本文是`7天用Go从零实现分布式缓存GeeCache教程系列`的第一篇。- 介绍常用的三种缓存淘汰(失效)算法：`FIFO`，`LFU` 和 `LRU`- 实现`LRU `缓存淘汰算法，代码约`80`行
2024-07-18 00:26:24
581
原创 day0 序言
而且，针对不同的应用场景，还需要在不同的特性之间权衡，例如，是否需要支持缓存更新？)，即通过增加单个节点的计算、存储、带宽等，来提高系统的性能，硬件的成本和性能并非呈线性关系，大部分情况下，分布式系统(水平扩展）是一个更优的选择。天实现，每天完成的部分都是可以独立运行和测试的，就像搭积木一样，每天实现的特性组合在一起就是最终的分布式缓存系统。
2024-07-18 00:01:33
794
原创 day6 模板(HTML Template)
本文是 `7天用Go从零实现Web框架Gee教程系列`的第六篇。- 实现静态资源服务(`Static Resource`)。- 支持`HTML`模板渲染。
2024-07-17 22:16:33
861
原创 day5中间件Middleware
本文是 7天用Go从零实现Web框架Gee教程系列的第五篇。设计并实现 Web 框架的中间件(Middlewares)机制。实现通用的Logger中间件，能够记录请求到响应所花费的时间，代码约50行
2024-07-17 00:21:25
972
原创 day4 分组控制Group
本文是 7天用Go从零实现Web框架Gee教程系列的第四篇。实现路由分组控制(Route Group Control)，代码约50行。
2024-07-16 23:49:22
538
原创 day3 前缀树路由
本文是 `7天用Go从零实现Web框架Gee教程系列`的第三篇。主要内容：- 使用 `Trie `树实现动态路由(`dynamic route`)解析。- 支持两种模式:`name`和`*filepath`，代码约`150`行。
2024-07-14 23:23:13
770
原创 day2 上下文Context
本文是 `7天用Go从零实现Web框架Gee教程系列`的第二篇。主要内容如下：- 将路由(`router)`独立出来，方便之后增强。- 设计上下文(`Context`)，封装 `Request` 和 `Response` ，提供对 `JSON`、`HTML `等返回类型的支持。
2024-07-14 21:45:54
888
原创 day1 HTTP基础
本文是 7天用Go从零实现Web框架Gee教程系列的第一篇，本篇将包含以下内容：简单介绍net/http库以及http.Handler接口。搭建Gee框架的雏形，代码约50行。
2024-07-14 20:33:37
938
原创 day0 序言
时间关系，同时为了尽可能地简洁明了，这个框架中的很多部分实现的功能都很简单，但是尽可能地体现一个框架核心的设计原则。例如Router的设计，虽然支持的动态路由规则有限，但为了性能考虑匹配算法是用Trie树实现的，Router最重要的指标之一便是性能。在设计一个框架之前，我们需要回答框架核心为我们解决了什么问题。当我们离开框架，使用基础库时，需要频繁手工处理的地方，就是框架的价值所在。不同的框架设计理念和提供的功能有很大的差别。那么理解这个微框架提供的特性，可以帮助我们理解框架的核心能力。
2024-07-14 16:58:36
414
原创 1、项目目录设计
本项目我们将会完成一个Go项目开发框架，该项目不会包含具体的CRUD业务代码，而是从头搭建一个工作中实用的开发框架。让开发者能够熟悉整个项目的搭建流程，能够独立完成项目从0到1的搭建，而且后续业务项目都可以复用该框架快速进入需求开发。
2024-07-11 22:54:47
188
原创 131. 面试中关于架构设计都需要了解哪些内容？
预先设定主键的生成规则，根据规则进行数据的分片路由，但这种方式会侵入商品各条线主数据的业务规则，更好的方式是基于分片元数据服务器（即每次访问分片前先询问分片元服务器再路由到实际分片），不过会带来复杂性，比如如何保证元数据服务器的一致性和可用性。大部分的系统，是要进行多轮拆分的，第一次拆分，可能就是将以前的多个模块该拆分开来了，比如说将电商系统拆分成订单系统、商品系统、采购系统、仓储系统、用户系统等等吧。因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，
2024-05-24 22:55:57
828
原创 130. MySQL表结构设计18条最佳实践原则
对于后端开发同学来说，访问数据库，是代码中必不可少的一个环节。等。后端开发的日常工作，需要不断的建库和建表，来满足业务需求。通常情况下，建库的频率比建表要低很多，所以，我们这篇文章主要讨论建表相关的内容。如果我们在建表的时候不注意细节，等后面系统上线之后，表的维护成本变得非常高，而且很容易踩坑。今天就跟大家一起聊聊，数据库建表的18个小技巧。文章中介绍的很多细节，我在工作中踩过坑，并且实践过的，非常有借鉴意义，希望对你会有所帮助。
2024-05-22 00:22:59
1039
原创 129.跨服务（跨数据库）多表存在大量数据依赖问题解决方案
相对1中介绍的原始方案，虽然还是需要先查商品表，然后用in查订单表，但是避免了RPC调用，上面的两次查询是在一个DB中进行的。如果需要关联使用商品数据的订单，采购服务的开发人员也无须关注商品数据的同步问题，只需要在查询时加上关联语句即可，实现了双赢。根据表结构不难发现，订单和采购单中保存的是商品ID，所以要实现上诉需求，需要先通过在商品表中获取到商品ID，然后去订单表查找订单，或去采购表查找采购单。每次更新商品时，先发布一条消息，订单与采购服务则各自订阅这条消息，消费消息各自更新商品冗余数据。
2024-05-21 00:33:56
860
原创 128.数据异构提升查询效率
冷热分离126.数据冷热分离方案与数据异构127.数据异构方案。本文介绍他们的实际应用场景实践。查询冷数据慢业务无法修改冷数据冷数据多到一定程度系统依旧扛不住此时如果需要解决以上问题，可以采用另外一种方案：使用查询分离优化业务主表数据大、查询缓慢的问题什么时候触发查询分离？如何实现查询分离？查询数据的存储系统选型？查询数据如何使用？查询分离的适用场景？当你在实际业务中遇到以下情形，则可以考虑使用查询分离解决方案。数据量大；所有写数据的请求效率尚可；查询数据的请求效率很低。
2024-05-20 23:46:34
946
原创 127.数据异构方案
何谓数据异构：把数据按需（数据结构、存取方式、存取形式）异地构建存储。比如我们将DB里面的数据持久化到Redis或者ES里面去，就是一种数据异构的方式。常见应用场景分库分表中有一个最为常见的场景，为了提升数据库的查询能力，我们都会对数据库做分库分表操作。比如订单库，开始的时候我们是按照订单ID作为分片键去分库分表，后来的业务需求想按照商家维度去查询，比如想查询某一个商家下的所有订单，就非常麻烦。异构维度数据异构总结起来大概有以下几种场景数据库镜像（DB→DB）数据库实时备份。
2024-05-20 23:21:10
961
原创 126.数据冷热分离方案
无论多么复杂的业务场景，一条数据的一生都体现在CRUD操作上，即创建、查询、修改、删除。一条数据随着时间的流逝，其价值也是在逐渐变小。数据存在的价值则是在于它被使用的程度，在不同的系统中，人们对于不同时期的数据有着不同的需求。比如12306、携程上的火车、机票订单，人们往往只关注30天之内的订单，而携程正是默认只保留30天的订单信息，超过30天的订单需要通过手机号查找。携程为什么要这么做？其实仔细想想不难明白，作为全国购票平台，每年数以亿计的订单，如果全部能够开放操作（CRUD），那么系统将会瞬间崩溃。
2024-05-20 22:51:15
787
原创 125. MySQL操作时的相关坑和处理技巧
在该程序刚部署成功，但数据库新字段还没来得及加的这段时间内，最新程序中，所有使用了新加字段的增删改查。才能把数据修复好，这种情况建议把表备份多次，如果出现异常，把数据回滚到最近的一次备份，可以节省很多重复操作的时间。这时所有涉及该字段的增删改查，都会报字段不存在的异常。正常情况下，如果程序新加了字段，一般是先在数据库中加字段，然后再发程序的最新代码。语句，通过上面的修改人和修改时间字段，在需要回滚时，能快速的定位到正确的数据。如果数据库中新加的字段非空，最新的程序还没发，线上跑的还是老代码，这时如果有。
2024-05-10 21:29:51
850
原创 124. explain | 索引优化 详解
对于互联网公司来说，随着用户量和数据量的不断增加，慢查询是无法避免的问题。一般情况下如果出现慢查询，意味着接口响应慢、接口超时等问题。如果是高并发的场景，可能会出现数据库连接被占满的情况，直接导致服务不可用。慢查询的确会导致很多问题，我们要如何优化慢查询呢？监控sql执行情况，发邮件、短信报警，便于快速识别慢查询sql打开数据库慢查询日志功能简化业务逻辑代码重构、优化异步处理sql优化索引优化其他的办法先不说，后面有机会再单独介绍。
2024-05-10 20:40:42
991
原创 123. SQL优化技巧汇总
sql优化是一个大家都比较关注的热门话题，无论你在面试，还是工作中，都很有可能会遇到。如果某天你负责的某个线上接口，出现了性能问题，需要做优化。那么你首先想到的很有可能是优化sql语句，因为它的改造成本相对于代码来说也要小得多。那么，如何优化sql语句呢？这篇文章从15个方面，分享了sql优化的一些小技巧，希望对你有所帮助。
2024-05-09 20:36:26
1068
原创 122. Kafka问题与解决实践
假如有家公司是做餐饮系统的，每天中午和晚上用餐高峰期，系统的并发量不容小觑。为了保险起见，公司规定各部门都要在吃饭的时间轮流值班，保证出现线上问题时能够及时处理。有个后厨显示系统团队【面向的是厨师和服务员】，该系统属于订单【面向用户】的下游业务。用户点完菜下单后，订单系统会通过发kafka消息给我们系统，系统读取消息后，做业务逻辑处理，持久化订单和菜品数据，然后展示到划菜客户端。这样厨师就知道哪个订单要做哪些菜，有些菜做好了，就可以通过该系统出菜。
2024-05-07 20:32:24
1045
原创 121. 使用MQ可能存在的问题以及解决办法
MQ的重要性不言而喻。我们为什么要用mq？引入mq可能会出现哪些问题？如何解决这些问题？你心中是否有答案了呢？本文将会一一为你解答，这些看似平常却很有意义的问题。
2024-05-07 16:44:54
749
原创 120.幂等设计实践
接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。比如：公交车刷卡，用户上车后刷码支付扣款成功，如果用户再次刷卡并扣款成功，用户查询余额返发现多扣钱了，流水记录也变成了两条,这就没有保证接口的幂等性。因此，当你重复刷卡时，会提示：刷码重复【每次打开支付码都会生成一个新的支付二维码，一个码只会完成一次支付，多次扫同一个二维码，只有第一次能支付成功】。注意：数据库可能产生幂等性问题，但是幂等性问题不只发生在数据库。
2024-05-07 15:58:43
1012
原创 119. 再谈接口幂等性
在93. 通用防重幂等设计一文中，已经介绍过幂等的使用。该文将补充一些其他方案，不一定实用，但是是思路的延伸。有时我们在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样。我们在项目中为了解决接口超时问题，通常会引入了重试机制。第一次请求接口超时了，请求方没能及时获取返回结果（此时有可能已经成功了），为了避免返回错误的结果（这种情况不可能直接返回失败吧？），于是会对该请求重试几次，这样也会产生重复的数据。mq消费者在读取消息时，有时候会读取到重复消息。
2024-05-07 15:03:46
862
原创 118. 性能优化技巧合集
本文梳理和总结了优化接口的18种方案，应该说比较系统了，大家在平时的学习或工作中也可以针对性地用起来。原文地址：https://mp.weixin.qq.com/s/fcUYP_6wFTp4y_tYSxf0xQ。
2024-05-06 21:04:41
728
原创 19.创建帖子
这里要稍微注意的是：需要登录后才可以发表帖子，所以需要用到我们之前写的鉴权中间件。为了文档看起来更清晰，我这里将中间件的代码和从。中能取出用户信息，说明鉴权成功，否则失败。解析成功后，便会将用户信息存入。可以看到是创建成功的。
2024-03-13 22:46:09
447
原创 17.获取帖子列表
一样了，需要返回作者名字和社区详情，所以我们还需要额外定义一个。开发GetPostListHandler。由于返回给前端的字段不完全和。
2024-03-13 21:44:12
458
原创 107. 如何使用Docker以及Docker Compose部署Go Web应用
使用Docker容器能够极大简化我们在配置依赖环境方面的操作，但同时也对我们的技术储备提了更高的要求。对于Docker不管你是熟悉抑或是不熟悉，技术发展的车轮都滚滚向前。原文地址：https://www.liwenzhou.com/posts/Go/deploy-in-docker/
2024-03-12 16:40:08
1132
原创 106. Dockerfile通过多阶段构建减小Golang镜像的大小
多阶段构建允许多个不同的构建过程，这些构建可以完全从不同的基础镜像构建，选择性地将文件从一个阶段传递到下一个阶段，从而剥离最终镜像中所有不必要的文件。我会说是的，但是为了实验的缘故，我们还是尽量挑战一下极限。我们继续沿着多阶段构建的道路前进，但这次在我们的第二阶段，我们将不再使用。差异可能会产生巨大的影响，在其余的情况下，你最终会在生产中得到一个完全没有任何工具的容器，我完全不推荐这样做。CGO_ENABLED=0 是至关重要的，如果我们不构建自包含的可执行文件，多阶段构建过程将无法工作。
2024-03-12 15:50:05
559
原创 105. Dockerfile详解
Dockerfile是用于构建Docker容器镜像的文本文件，它包含了一系列指令和配置，用于描述如何组装一个Docker容器的环境。通过Dockerfile，你可以自动化地构建镜像，确保在不同的环境中都可以复现相同的容器。Dockerfile中的指令可以指定从哪个基础镜像开始构建、复制文件到镜像中、安装软件包、设置环境变量、暴露端口、运行命令等等。每个指令都会在镜像的构建过程中创建一个新的镜像层，这些层构成了最终镜像的结构。这种分层结构让镜像的构建更加高效，同时也方便了镜像的复用和共享。以下是一个简单的。
2024-03-12 11:54:27
1018
原创 104. Go单测系列4---编写可测试的代码
本文是Go单测系列的最后一篇，在这一篇中我们不再介绍编写单元测试的工具而是专注于如何编写可测试的代码。编写可测试的代码可能比编写单元测试本身更加重要，可测试的代码简单来说就是指我们可以很容易的为其编写单元测试代码。接下来，我们将通过几个简单示例来介绍如何编写可测试的代码。
2024-03-11 21:03:25
1053
2
原创 103. Go单测系列3---mockey与convey综合实战
工作中，随着业务的快速发展，代码量级和复杂度也会随之快速增长，面临的稳定性挑战越来越大。单测作为稳定性保障的重要一环越来越受到重视，编写单元测试应该成为程序员的基本素养。之前写单元测试都是基于go自己的test方式，基本就是在线下跑通流程，遇到下游的接口无法访问时，只会束手无策。后来了解到一些单测工具，市面上已有很多成熟的单测工具，本文不会比较各种工具的优劣，而是结合自身经验介绍本人在工作时常用的工具。
2024-03-11 20:35:23
1809
1
原创 102. Go单测系列2---goconvey的使用
GoConvey是一个非常非常好用的Go测试框架，它直接与go test集成，提供了很多丰富的断言函数，能够在终端输出可读的彩色测试结果，并且还支持全自动的Web UI。安装如果需要使用goconvey的Web UI程序，请执行下面的命令安装可执行程序。如果只是想在项目中引入依赖，只需要在项目目录中执行以下命令。使用示例我们使用goconvey来为最开始的基础示例中的Split函数编写单元测试。
2024-03-11 20:33:44
542
1
原创 101. Go单测系列1---使用monkey打桩
单元测试中十分常用的打桩工具，它在运行时通过汇编语言重写可执行文件，将目标函数或方法的实现跳转到桩实现，其原理类似于热补丁。Debug 模式下跑单个测试时会自动带上该参数，Run 模式下跑单个测试或者跑一个包的测试则需要手动带上该参数。但是当你编写代码的时候这个库还没实现，或者这个库要经过内网请求但你现在没这能力，这个时候要为。熟练使用各种打桩工具能够让我们更快速地编写合格的单元测试，为我们的软件保驾护航。不是线程安全的，所以不要把它用到并发的单元测试中。不支持内联函数，在测试的时候需要通过命令行参数。
2024-03-11 20:12:16
653
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人