time_wait过多的危害 第一是内存资源占用，这个目前看来不是太严重，基本可以忽略。 第二是对端口资源的占用，一个 TCP 连接至少消耗一个本地端口。要知道，端口资源也是 有限的，一般可以开启的端口为 32768～61000 ，也可以通过net.ipv4.ip_local_po rt_range指定，如果 TIME_WAIT 状态过多，会导致无法创建新连接。这个也是我们在一 开始讲到的那个例子 怎么避免time_wait过多 net.ipv4.tcp_max_tw_buckets 一个暴力的方法是通过 sysctl 命令，将系统值调小。这个值默认为 18000，当系统中处于 TIME_WAIT 的连接一旦超过这个值时，系统就会将所有的 TIME_WAIT 连接状态重置，并 且只打印出警告信息。这个方法过于暴力，而且治标不治本，带来的问题远比解决的问题 多，不推荐使用 调低 TCP_TIMEWAIT_LEN，重新编译系统 这个方法是一个不错的方法，缺点是需要“一点”内核方面的知识，能够重新编译内核。我 想这个不是大多数人能接受的方式。 SO_LINGER 的设置 1 2 int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen); 1 2 3 4 struct linger { int l_onoff; /* 0=off, nonzero=on */ int l_linger; /* linger time, POSIX specifies units as seconds */ } 如果l_onoff为非 0， 且l_linger值也为 0，那么调用 close 后，会立该发送一个 RST 标志给对端，该 TCP 连接将跳过四次挥手，也就跳过了 TIME_WAIT 状态，直接关 闭。...
文章
自我介绍： 你好，我叫蒋贻华，毕业于浙江师范大学计算机专业。此前有7年的php开发经验， 后来由于公司技术栈的变更，转到golang方向，目前有3年的Golang开发经验。 下面介绍一下我在过往的工作经历里充当的角色与主要的职责。 在广州趣丸科技有限公司，我主要负责匿名社交产品uki的新功能的方案设计及开发与老功能的迭代优化。 在功能模块的迭代上，负责了会员等级模块，匹配模块，其他老服务代码的迁移。 在性能优化上，从业务上寻找存在瓶颈或者影响系统稳定性的问题，并进行改造，比如包括缓存的优化、 Redis/MySQL慢查询的优化和对敏感操作的分布式事务重写，在中间件上添加限流熔断。 在商米科技有限公司，这是一家智能硬件设备的公司，正在探索软件生态上的一些机会， 我主导从0到1开发一套远程设备管理系统。这套系统是一个基于mqtt协议的长链接， 通过网页端下发指令控制设备的一些操作，包括对设备的关机、重启、传输文件、上传日志等指令。 我负责技术选型、压测上线，以及预算成本控制等工作， 最终我们的集群是由7台4核8G的机器组成，目前能够维持百万以上设备同时在线。 此外，针对此套长链接还为整个公司提供了推送基础服务， 在19年度成为该公司的年度最佳员工之一。
缓存改造 增加singlefight，防止缓存穿透，但也不能直接用，如果并发量大，而请求的数据太慢，可能会导致整个系统的请求都超时 singleFight 直接用可能存在的问题 出现上述问题的根本原因是以下两点： 阻塞读：缺少超时控制，难以快速失败； 单并发：虽然达到了控制并发的效果，但是牺牲了成功率； 超时控制 ，用DoChan替代Do，DoChan() 通过 channel 返回结果。因此可以使用 select 语句实现超时控制 降低请求数量： 在一些对可用性要求极高的场景下，往往需要一定的请求饱和度来保证业务的最终成功率。 一次请求还是多次请求，对于下游服务而言并没有太大区别，此时使用 singleflight 只是为了降低请求的数量级，那么使用 Forget() 提高下游请求的并发 多级缓存 在redis之前再加一层内存缓存。之前也是直接用了公司那边自己写的缓存框架，就是没有多map分片，如果整个内存的缓存数据的key多的话， 我们都知道，map是不能并发读写的。 根据调研，也是选择了性能相对高的缓存框架，因为之前选择了groupCache这种的，但实际上有很多小对象的缓存，导致gc频繁， 后面也是选择了freecache，来保证性能的平衡 支持http协议 支持 10K RPS (5k 写，5k 读) cache对象至少保持10分钟 相应时间平均 5ms, p99.9 10毫秒， p99.999 400毫秒 其它HTTP的一些需求 为了满足这些需求,要求开发的cache库要保证： 即使有百万的缓存对象也要非常快 支持大并发访问 一定时间后支持剔除 https://colobu.com/2019/11/18/how-is-the-bigcache-is-fast/
feed流的优化 关注feed流 - 读扩散 原理 读扩散需要先读取关注列表中的用户，然后分别按时间线去读取关注列表用户的动态列表， 关注feed流 - 写扩散 读写比例是100:1，也就是说大部分情况都是刷Feed流看别人发的朋友圈和微博，只有很少情况是自己亲自发一条朋友圈或微博给别人看。 因此，读扩散那种很重的读逻辑并不适合大多数场景。 每次发表帖子，都会扩散为M次写操作（M等于自己的粉丝数） 读写混合模式 |方案 |优点 |缺点 |适用场景| |读扩散 |节约存储空间，发帖操作简单 |读帖操作复杂，关注人数多时是灾难 用户不活跃，很少读帖；有大V粉丝量多，但每个粉丝关注的人少| |写扩散 |读帖操作简单 发帖操作复杂，浪费存储空间；大V粉丝量多时是灾难 用户非常活跃，经常刷帖；无大V，用户粉丝量都比较少| 粉丝量大的主播发送动态，写扩展给其活跃用户，粉丝量小的，直接写扩展给其所有的粉丝。 活跃的用户上线，直接读其feed流 非活跃的用户突然登录刷Feed流时，我们一方面需要读他的feed流，另一方面需要遍历他所关注的大主播的动态列表，做一下聚合展示。在展示完后，系统还需要有个任务来判断是否有必要将该用户升级为活跃用户。 因为有读扩散的场景存在，因此即使是混合模式， 读写混合模式下，系统需要做两个判断。一个是哪些用户属于大V，我们可以将粉丝量作为一个判断指标。另一个是哪些用户属于活跃粉丝，这个判断标准可以是最近一次登录时间等。这两处判断标准就需要在系统发展过程中动态地识别和调整，没有固定公式了。 https://www.6aiq.com/article/1628640265887 https://mp.weixin.qq.com/s?__biz=MzU0OTE4MzYzMw==&mid=2247486929&idx=4&sn=e0937dc99cfe853e416a930633dd7db3&chksm=fbb2842fccc50d393183ea602d6c2a7954530dd8a0a33583f007b7cefb458566a4ff4587889a&scene=27
1. 对用户大key的拆分 将最常用的几个值拆分出来，之前是全部的一条用户信息直接压缩存到redis中，但是有一个很严重的问题，就是随着业务越来越复杂，读取的 会越来越频繁，那么对整个大key的读取将会变慢，有一次就是要显示一个千人千面的用户推荐列表，然后就频繁的读取这种用户信息，直接网络的 读写io占满，后面是把这种key拆分成小key处理 2. Redis其实只适合作为缓存，而不是数据库或是存储。 之前太多的业务使用redis存储，但好多不设置过期时间，导致最后redis的内存迟迟不放，所以得所有的key最好都设置过期时间。 哪怕设置成一年这么长，也比没设置好，长时间的不释放，会导致生成rdb这些，内存占用这些都有影响 3. 客户端连接池占满 开启查询自旋模式，容易占用连接池
你好，我叫蒋贻华，目前在寻找新的工作机会，目前想找的方向是golang后端开发。 对贵司的golang开发岗位感兴趣，我认为我过往的工作经验与贵公司有一定的匹配度，希望有机会更深入的了解下。 主要主要从事的行业领域主要社交app与智能硬件方向 跟您详细聊完后，对岗位还是挺有意向的，可以安排一场面试吗？
尼康d750可以有三种方式来自拍，一是使用间隔拍摄，可以设置拍摄时间与间隔，然后再拍摄。 第二种就是相机的第二个轮盘(调整ASPM的轮盘下方)设置到有个指针的那个，会自动延时10秒拍摄。 第三种就是连接手机app，进行遥控。个人更喜欢第一种吧，时间可以调。
针对对焦方式，一般拍静物时，使用单点对焦，就是AFS。如果拍运动中的，使用AFC 3d模式。 拍人像，优先对焦眼部，没眼部对焦脸部 调节对焦方式。相机里AF/MF中里面有个按钮可以快速调整