Algorithm
- 题目: 组合总和
- 解题思路:
- 回溯,关键是招够 n 个数,并且不能重复,没法直接遍历,因为循环层数不固定
- 遍历过程中,如果后选择的数字肯定比已经选择的数字大,即遍历时从上次选择的数字的后一个数字开始选,可以保证不重不漏
- 回溯代码要素
- dfs 访问决策树
- 路径:暂时选中的数字
- 选择列表:还没遍历过的数字
- 选择动作:
- 将遍历到的元素 i 添加到 selected 列表中
- 更新选择的数字之和 sum, sum += 1
- 将上次选择的结果更新成 i
- 撤销选择
- 从 sum 中将当前元素减掉
- 删除选择列表中最后一个数字
- 将上次选择结果更新成新的最后一个元素
- 剪枝
- 在尝试添加遍历到的元素 i 之前,先检查 sum + i > n 是否成立,如果成立则剪枝
- 代码
1 | public class CombinationSum { |
- 一个小坑
- 一开始总发现返回的结果中只有一个元素的 List<List
>,并且这个元素是个空列表,结果没加进去 - 原因: add 结果时是传引用, 因此后面再回溯时就把 combinations 结果里的元素全给删掉了
- 解决办法:往 combinations 里添加结果时新建一个 list,把符合条件的选择列表复制过去
- 一开始总发现返回的结果中只有一个元素的 List<List
Review
原文地址:Prometheus - Service Discovery
本文介绍了为 Prometheus 开发服务发现机制时,需要注意的问题,有几个要点
- 服务发现组件应该是个很通用的组件,逻辑很少,只关注将“服务元数据”暴露给 prometheus
- 对于自定义的需求,推荐使用 “FileSD”
- SD 暴露给 Prometheus 时需要注意几个问题
- SD 应该通过 KV 暴露给 Prometheus 元数据,pattern 为
__meta_<sdname>_<key>
,地址应该通过__address__
标签来暴露,包含host
和port
,数组应该 join 到一个字符串里,例如[a,b,c]
应该是,a,b,c,
- SD 本身应该没什么逻辑,过滤、转换等逻辑应该通过 relabel 来实现
- SD 过程中如果出错,应该返回旧的发现结果,而不是部分结果
If there is a failure while processing talking to the SD, abort rather than returning partial data. It is better to work from stale targets than partial or incorrect metadata.
- 一个 SD 如果有多种类型,应该通过配置文件来显示指定类型,而不是一个大的 SD 通过 relabel 来过滤,例如
kubernetes
- SD 应该倾向发现所有潜在的监控目标
- SD 应该通过 KV 暴露给 Prometheus 元数据,pattern 为
- 总结
- SD 应该只关注如何发现监控目标,并且 SD 暴露出来的应该是最原始的元数据
- 发现 target 元数据和基于元数据进行过滤、转换的事情应该分离开,SD 和 relabel 配合紧密
Tips
- 遇到问题要弄清楚背后的原因,不要只满足于现象本身
- 重要的事情,及时加到日程安排里,防止遗忘、对外可见
- 自己不熟悉的事情,准备好问题,提早找更资深的人请教往往会更高效