Kubernetes 中， 容器总是以 Pod（容器组）的方式进行调度与运行。因此对 Pod 的理解与掌握是学习 Kubernetes 的基础。

最近一次移动端Vue应用的上线，导致某些用户使用某些功能时出现问题，经主动清空缓存后恢复。有时候清空微信应用的存储空间缓存仍不能解决问题，此时安卓机可借助微信TBS调试工具 http://debugx5.qq.com （微信中打开页面，勾选最下面四个选项清除缓存），但该工具目前只支持安卓手机，苹果机就比较麻烦了。为了找到问题的本质，从根本上避免问题，最近浏览了一些文章，其中有一篇对浏览器缓存的分析及在Nginx中对应的处理策略总结的比较好，这里分享给大家。

上篇文章（限流算法与Guava RateLimiter解析）对常用的限流算法及Google Guava基于令牌桶算法的实现RateLimiter进行了介绍。RateLimiter通过线程锁控制同步，只适用于单机应用，在分布式环境下，虽然有像阿里Sentinel的限流开源框架，但对于一些小型应用来说未免过重，但限流的需求在小型项目中也是存在的，比如获取手机验证码的控制，对资源消耗较大操作的访问频率控制等。本文介绍最近写的一个基于RateLimiter，适用于分布式环境下的限流实现，并使用spring-boot-starter的形式发布，比较轻量级且“开箱即用”。

在分布式系统中，应对高并发访问时，缓存、限流、降级是保护系统正常运行的常用方法。当请求量突发暴涨时，如果不加以限制访问，则可能导致整个系统崩溃，服务不可用。同时有一些业务场景，比如短信验证码，或者其它第三方API调用，也需要提供必要的访问限制支持。还有一些资源消耗过大的请求，比如数据导出等（参考 记一次线上Java服务CPU 100%处理过程 ），也有限制访问频率的需求。

分布式锁是在分布式环境下（多个JVM进程）控制多个客户端对某一资源的同步访问的一种实现，与之相对应的是线程锁，线程锁控制的是同一个JVM进程内多个线程之间的同步。分布式锁的一般实现方法是在应用服务器之外通过一个共享的存储服务器存储锁资源，同一时刻只有一个客户端能占有锁资源来完成。通常有基于Zookeeper，Redis，或数据库三种实现形式。本文介绍基于Redis的实现方案。

告警

正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。

赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。

一同事求援：后台系统的登录成功了，但不能成功登进系统，仍然跳转到登录页，但同一套代码另一个环境却没有问题。

前面我们对K8s的基本组件与概念有了个大致的印象，并且基于K8s实现了一个初步的CI/CD流程，但对里面涉及的各个对象（如Namespace, Pod, Deployment, Service, Ingress, PVC等）及各对象的管理可能还缺乏深入的理解与实践，接下来的文章就让我们一起深入K8s的各组件内部来一探究竟吧。下图是基于个人的理解梳理的一个K8s结构图，示例了各个组件（只包含了主要组件）如何协同。

k8s集群运行过程中，经常出现节点上报出类似 “kernel:unregister_netdevice:waiting for vethxxx to become free. Usage count=1” 的错误信息，一方面影响交互，另一方面，对于有些操作比如 docker stop，半天没有响应，处于hang住的状态。

单例模式是保证一个类的实例有且只有一个，在需要控制资源（如数据库连接池），或资源共享（如有状态的工具类）的场景中比较适用。如果让我们写一个单例实现，估计绝大部分人都觉得自己没问题，但如果需要实现一个比较完美的单例，可能并没有你想象中简单。本文以主人公小雨的一次面试为背景，循序渐进地讨论如何实现一个较为“完美”的单例。本文人物与场景皆为虚构，如有雷同，纯属捏造。