看了周玉强老师讲的K8S集群实战,感觉门槛降低了好多,一年前看K8S,真的是好麻烦。
基本特性
- 自我修复
- 服务发现与自动负载均衡
- 自动部署和回滚,并且支持按版本回滚
- 弹性伸缩
1. 环境准备
| 主机名 | IP 地址 | 角色 |
|---|---|---|
| k8s-master | 10.0.0.11 | master, node |
| k8s-node1 | 10.0.0.12 | node |
| k8s-node2 | 10.0.0.13 | node |
偶然想到,文章正确的顺序是什么。解决问题的办法放最后,前边一堆铺垫吊胃口?那就反过来吧,正如
有余力则学文。
一、缓存释放办法
-
清理
page_cache(page_cache是硬盘和内存之间的缓存):sync && echo 1 > /proc/sys/vm/drop_caches
-
清理可回收的
slab对象(包括目录缓存、文件缓存):sync && echo 2 > /proc/sys/vm/drop_caches
-
清理
slab对象和page_cache:sync && echo 3 > /proc/sys/vm/drop_caches
索引可以包含一列或多列,如果是多列,列的顺序也十分重要;创建一个包含两列的索引,和创建两个一列的索引是大不相同的。
目录
- 索引分类
- 索引命名规范
- 测试表SQL
- 索引设计原则
- 索引优化实战
1、索引分类
- 主键索引(Primary Key)
- 唯一索引(Unique Key)
- 普通索引(Normal Key)
看源码知道单例池就是一个 Map<beanName, object>
DefaultSingletonBeanRegistry#singletonObjects
不知道 singletonObjects 到底是什么时候将对象 put 进去的?
1、断点设置个条件,只拦截 beanName为 a的 Bean

Spring 源码学习,一方面提升读源码能力、向大师学习;一方面便于更深入地使用、拓展 Spring。
- 本人呢,还是喜欢把学的记录下来,写的过程,也是加深理解的过程。毕竟你可能只是感觉会了。
- 编译了 Spring 源码,学着就更方便了
系统地学习下,更好地理解 Dubbo + ZK,Kafka + ZK 等等
文件系统 + 通知机制
是一种基于观察者模式的分布式服务管理框架,他负责存储和管理大家都关心的数据,然后接受观察者的注册,
一旦这些数据的状态发生变化,Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的
反应,从而实现集群中类似Master/Slave管理模式
基础须知
它是个类文件系统,每个
znode目录节点都可以正常地增加、删除,不一样的是znode可以保存数据。默认每个
znode只能保存1MB数据。如需扩展zkEnv.sh后边加上-Djute.maxbuffer=10240000。
项目稳定运行,但难免会有些操作引发CPU飙高,怎么处理呢?
附源码:模拟CPU飙高,while(true)
道路千万条,开车第一条
不要慌,不要慌,不要慌
jps查看进程IDjps或者jps -l- eg. 拿到进程ID
795
top查看进程实时监控,拿到CPU飙高的线程ID()top -Hp 795- eg. 拿到CPU飙高的线程ID
841
- 将上一步线程ID转换为十六进制
printf "%x\n" 841- eg. 拿到十六进制线程ID
349
jstack堆栈跟踪工具jstack 795|grep 349 -A 30- 报错
well-known file is not secure对应PID的启动用户不是当前用户
设计模式, 代码的孙子兵法
黑色三月 >>> 学习·祭奠·不凡
2019.3又是三月 >>> 学习·巩固·提高
2020.3
一、原则
- 单一职责原则
就一个类而言,应该仅有一个引起它变化的原因。
- 开闭原则
软件实体(类、模块、函数等等)应该可以扩展,但是不可以修改。
- 依赖倒置原则
要针对接口编程,不要对实现编程。
- 高层模块不应该依赖低层模块,两个都应该依赖抽象;
- 抽象不应该依赖细节,细节应该依赖抽象。
- 里式替换原则
子类型必须能够替换掉他们的父类型。
- 接口隔离原则
细化接口,但要适中,不大不小方为最佳实践。
- 客户端不应该依赖它不需要的接口;
- 类间的依赖关系应该建立在最小的接口上。
- 迪米特原则
如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。
如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。
未整理内容
无