Canger_的博客

I/O密集型和CPU密集型 对于IO/Network瓶颈类的程序，其表现是网卡/磁盘IO会先于CPU打满，这种情况即使优化CPU的使用也不能提高整个系统的吞吐量，只能提高磁盘的读写速度，增加内存大小，提升网卡的带宽来提升整体性能。而CPU瓶颈类的程序，则是在存储和网卡未打满之前CPU占用率先到达100%，CPU忙于各种计算任务，IO设备相对则较闲。 无论哪种类型的服务，在资源使用到极限的时候都会导致请求堆积，超时，系统hang死，最终伤害到终端用户。对于分布式的Web服务来说，瓶颈还不一定总在系统内部，也有

为什么需要锁 单机程序，在多线程并发情况下，操作同一资源时，需要对其进行加锁等同步措施来保证原子性。举一个多线程自增的例子： package main import ( "sync" ) // 全局变量 var counter int func main() { var wg sync.WaitGroup for i := 0; i < 100; i++ { wg.Add(1) go func() { counter++

一、常见的负载均衡思路 1.1、按顺序挑： round robin式，例如上次选了第一台，那么这次就选第二台，下次第三台；如果到了最后一台，那么下次从第一台开始。 1.2、随机挑一个： 每次都随机挑，真随机伪随机均可。假设选择了第x台机器，那么x可被描述为rand.Intn()%n 1.3、根据某种权重挑选 对下游节点进行排序，选择权重最大/小那一个 实际场景下我们不可能无脑轮询或者无脑随机，如果对下游请求失败了，我们还需要某种机制来进行重试，如果纯粹的随机算法，存在一定可能性下次仍然随机到这次的问题

分布式id生成 一、 MySQL自增ID 二、Twitter的snowflake算法 2.1 snowflake的id生成 首先确定我们的数值是64位，int64类型，被划分为五部分： 第一个bit位不用，代表符号位 用41位来表示收到请求时的时间戳，单位为毫秒 5位数表示数据中心的ID 再5位数表示机器的实例ID 最后是12位的循环自增ID,到达 1111 1111 1111 后会归0 这样的机制可以支持我们在同一台机器上，同一毫秒内产生2^12 = 4096条消息，一秒则可以生成409.6w条消息，