删除数组元素
1 |
|
修改数据元素
1 |
|
根据条件更新指定的数组元素
1 |
|
线程池
那为什么 阻塞队列 入队要在 创建 最大线程数之前，队列满了 才 创建 除了核心线程外的新线程
因为创建/销毁线程是需要成本的，而且比较高 ，线程之间的上下文切换也是需要成本的
如果我处理当前的问题能以当前速率在可控时间之内处理完，我肯定不愿意增加新的成本
Git操作
Nacos_SPI机制
Nacos 源码中使用了大量的 SPI 来实现自定义扩展
定义了 NacosServiceLoader 用来加载 SPI 服务，底层使用的还是 JDK ServeicLoader。其核心定义了一个 Map 缓存 ServiceLoader 加载的 Class ，避免二次加载，提高效率
NacosApplicationListener
提供在 Nacos application 启动 ，环境准备，上下文准备，容器刷新时监听方法
自定义 SpringApplicationRunListener 实现接口 Spring 原生的 应用监听器接口 SpringApplicationRunListener。字段 nacosApplicationListeners 利用 SPI 机制加载了扩展的所有 NacosApplicationListener 实例，SpringApplicationRunListener 实现的所有监听方法都是依次调用 nacosApplicationListeners 的方法。
默认两个实现类
StartingApplicationListener
核心功能：注入 Spring 容器环境Bean，加载自定义配置文件（spring.config.additional-location），加载系统参数， 加载环境参数，
包括自定义的环境参数 CustomEnvironmentPluginManager
LoggingApplicationListener
- 用于初始化日志配置信息，META-INF/logback/nacos.xml
CustomEnvironmentPluginService
CustomEnvironmentPluginManager 字段 SERVICE_LIST SPI 加载自定义环境 CustomEnvironmentPluginService
默认无实现
限流插件- Control-Plugin
继承实现 ConnectionControlManager 完成Nacos应用的限流策略
Windows CMD
分库分表
分库分表是解决大流量、大数据量系统数据库层面的优化。
分为两种类型
Client ：Sharding-jdbc
Server：Mycat、sharding-proxy
带来的问题
深度分页、查询性能低下（多表，甚至跨库）：使用ES的宽表、通过 ETL 将数据清洗到 ES
数据倾斜：跟分表分库策略有关系。超级用户
分布式事务：例 使用消息中间件保证最终一致性
深分页问题：。。
如何平缓迁移老系统的数据？
目前大多数公司的数据库方案都不是一来就上分库分表（当然如果能够预料到数据体量，一开始就设计好这样最好，但是新业务的不确定性还是很大），因此存在老数据往新的分库分表数据库迁移的情况。
方案：双写不中断迁移
历史数据量大，肯定不能停机迁移。
方案1：
线上系统里所有写库的地方，增删改操作，除了对老库增删改，都加上对新库的增删改，使用方
系统部署以后，还需要跑程序读老库数据写新库，写的时候需要判断updateTime
循环执行，直至两个库的数据完全一致，最后重新部署分库分表的代码就行了
方案2：
新老服务均支持运行：
流量染色灰度发布，区分新、老服务。数据同步：定时同步、实时异步同步。稳定后网关将流量切换到新服务。
如何扩容？
2*n 参考 hashmap 的扩容机制
