Go 语言的协程 goroutine Go 为了提供更容易使用的并发方法, 使用了 goroutine 和 channel。goroutine 来自协程的概念, 让一组可复用的函数运行在一组线程之上, 即使有协程阻塞, 该线程的其他协程也可以被 runtime 调度, 转移到其他可运行的线程上。最关键的是, 程序员看不到这些底层的细节, 这就降低了编程的难度, 提供了更容易的并发。 Go 中, 协

参考 ： https://draveness.me/golang/docs/part3-runtime/ch06-concurrency/golang-channel https://www.bilibili.com/video/BV1kh411n79h 不要通过共享内存的方式进行通信, 而是应该通过通信的方式共享内存 Channel 是 Goroutine 之间的通信方式 12345678910

早上打开电脑摸鱼的时候发现公司的测试环境的一个微服务CPU单核占用率到了99%,因为是核心服务,一直以为是处理业务逻辑的原因, 下午的时候就飙到了199%,而且很稳定的维持中,发现不对劲,去其他环境一看,果然这个服务的CPU占用率都不正常, 很可惜没有对这个服务开启pprof,找不到具体原因, 看看代码, 很顺利找到原因 看到代码时立马想到了当年看过群主的这篇blog 原因还是锁抢占的问题 dem

Go八股文大全.pdf 提取码：b7ep Go面试题new.pdf 提取码：o399 Kubernetes in Action中文版.pdf 提取码：77r2 docker run -d --name etcd-server --publish 2379:2379 --publish 2380:2380 --env ALLOW_NONE_AUTHENTICATION=yes --env ET

docker 安装 NACOS NACOS 当前版本 2.2.2 123456789docker run -d -p 8848:8848 -p 9848:9848 -e MODE=standalone \-e PREFER_HOST_MODE=hostname \-e NACOS_AUTH_ENABLE=true \-e NACOS_AUTH_IDENTITY_KEY=test \-e NACO

微服务框架 go-micro 使用 Kafka 作为发布订阅的 Broker go-micro 默认使用http服务作为服务中的Broker 服务默认启动的时候 使用kafka启动 http服务作为服务中的Broker，有三个明显的缺点： 不能持久化存储 不能对未消费的数据，进行消费 每个需要发送消息的微服务都会启动一个 http Broker服务，可能会影响服务器性能 bro

服务器时间导致服务崩溃 测试反馈最近版本发布完,内网演示环境服务测试的时候,服务卡顿明细,让我找找问题 爬到服务器上一看,数据库负载到了20多 top + iostat 一看, 好家伙, 磁盘IO拉满了 假装分析一波发现 mongodump 这个进程在 top 中排第一位, 原来是在备份数据啊,忙问了一下领导, 回复说没有进行数据备份 仔细想了一下 crontab 里面有定时数据库备份的任务,凌晨

Kafka特点： 1 解耦合 消息队列提供了借口, 生产者和消费者能够独立的完成读操作和写操作。 2 高吞吐率。即使是在廉价的商用机器上也能做到单机支持每秒100K条消息的传输 3 信息传输快。以时间复杂度为O（1）的方式提供持久化能力, 即使对TB级以上数据也能保证常数时间的访问性能 4 可提供持久化。消息存储在中间件上, 数据持久化, 直到全部被处理完, 通过这一方式规避了数据丢失的风险

公司内网环境自建的 MinIO 作为对象存储,而外网的对象存储则是使用的阿里云服务 MinIO和阿里云 都兼容亚马逊(AWS) 的S3协议, 为此使用 AWS-SDK 上传服务生成的数据内容 docker 创建一个 MinIO 的容器 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD 就是 9001 端口的登录的账号密码, 也是AK和SK(也可以进入后台自己更换) 12d

etcd 超出空间导致服务注册不成功 keyword：mvcc: database space exceeded go-micro 使用etcd作为注册中心, 公司当前处于的是业务开发状态, 发布订阅功能也是直接基于go-micro 使用etcd来做消息转存的,导致消息发布有大量消息没有及时处理, 堆积下来, 然后新服务不能写入注册信息到etcd中 上网搜索了一下,官方文档已经写的很清楚了 ht