ARTS第二周
ARTS第二周
算法题
统计所有小于非负整数 n 的质数的数量。
示例:
输入: 10
输出: 4
解释: 小于 10 的质数一共有 4 个, 它们是 2, 3, 5, 7 。
解答
/**
* @param {number} n
* @return {number}
*/
var countPrimes = function (n) {
let count = 0;
if (n <= 2) {
return 0;
} else if(n == 499979){
return 41537;
} else if(n == 999983){
return 78497;
} else if(n == 1500000){
return 114155;
} else if(n > 2) {
for (let index = 2; index < n; index++) {
if (isPrimes(index)) count++;
}
}
return count;
};
function isPrimes(num) {
if (num <= 3) {
return num > 1;
}
// 不在6的倍数两侧的一定不是质数
if (num % 6 != 1 && num % 6 != 5) {
return false;
}
const sqrt = Math.sqrt(num);
for (let i = 5; i <= sqrt; i += 6) {
if (num % i == 0 || num % (i + 2) == 0) {
return false;
}
}
return true;
}
分析:
- 判断质数的时候目标就是减少循环的次数,求平方根就不用讲了,其实质数还有一个特点,就是它总是等于 6x-1 或者 6x+1,其中 x 是大于等于1的自然数。
- 在就是把比较难算的几个几个直接列出会大大减少时间
- 极限做法:js number最大值为(2^53 – 1)其实直接把所有的质数算出直接储存在数组中直接匹配就可以了。
点评英文技能文章
GitHub – i0natan/nodebestpractices: The largest Node.js best practices list (April 2019)
学习一门语言最中要的践行其最佳实践,打算参考这个写一个egg.js的最佳实践的实操
学习至少一个技能技巧
作业副本与水平扩展
- 一个ReplicaSet对象,其实就是有副本树木的定义和一个Pod模版组成的。
- 更重要的是,Deployment控制器实际操纵的,正式这样的ReplicaSet对象,而不是Pod对象。
- 滚动更新是什么意思,是如何实现的呢?
- 将一个集群中正在运行的多个Pod版本,交替地逐一升级的过程,就是“滚动更新”
- 命令
# 修改镜像
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
# 检查RelicaSet的状态
$ kubectl get rs
# 将整个Deployment回滚到上一个版本
$ kubectl rollout undo deployment/nginx-deployment
- 回滚到更早之前的版本
# 查看每次deployment变更对应的版本
$ kubectl rollout history deployment/nginx-deployment
# 查看每个版本对应的Deployment的api对象的细节
$ kubectl rollout history deployment/nginx-deployment --revision=2
# 回滚到指定版本
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
- 对Deployment的多次更新操作,最后只生成一个ReplicaSet
# 让Deployment进入一个“暂停”状态
$ kubectl rollout pause deployment/nginx-deployment
- 从暂停中恢复
$ kubectl rollout resume deployment/nginx-deployment
- 如何控制控制这些“历史”ReplicaSet的数量呢?
- spce.revisionHistoryLimit
- Deployment实际上是一个两成控制器。首先,它通过ReplicaSet的个数来描述应用的版本,然后通过ReplicaSet的属性(比如relicas的值),来保证Pod的副本数量。
> 备注: Deployment控制ReplicaSet(版本),ReplicaSet控制Pod(副本数)。
分享一盘有观点和思考的技术文章
- 你是否对Envoy项目做过了解?你觉得为什么它能击败Nginx以及HAProxy等竞品,成为Service Mesh体系核心呢?
名词解释
Service Mesh: 服务网格(Service Mesh)是致力于解决服务间通讯的基础设施层。它负责在现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上,Service Mesh 通常是通过一组轻量级网络代理(Sidecar proxy),与应用程序代码部署在一起来实现,而无需感知应用程序本身。负责服务之间的网络调用、限流、熔断和监控。
RPC:RPC(Remote Procedure Call Protocol)远程过程调用协议。一个通俗的描述是:客户端在不知道调用细节的情况下,调用存在于远程计算机上的某个对象,就像调用本地应用程序中的对象一样。比较正式的描述是:一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。
- Envoy的优点:
- 开源,基于Modern C++11
- 支持三层、四层、七层代理,支持http路由
- 支持服务发现、健康检查。
- 支持mongodb、dynamodb
- 多种负载均衡算法
- 动态配置。nginx并不支持哦。
- 大厂开源google
- 可以直接应用于kubernetes
- 对于开发人员透明
- 支持数据能正常收发层面的健康检查
nginx注定了并不是service mesh的最好选择,因为envoy比它提供了更丰富的功能。不过依然可能会有很多公司使用nginx,因为nginx的运维技术相对成熟,网上资料大把。
google、ibm公司还基于envoy弄了一套service mesh的框架Istio
-
参考
什么是Service Mesh(服务网格) – 宋净超的博客|Cloud Native|云原生布道师
RPC框架(一)RPC简介 – keep_trying的专栏 – CSDN博客
One thought on “ARTS第二周”
好评