• 关于

    用户节点可以做什么

    的搜索结果

问题

区域选择帮助

fanyue88888 2019-12-01 21:01:00 199572 浏览量 回答数 1

回答

我们服务器两国的用户;AWS国内节点和国外节点不同,阿里云亦然; AWS的CDN有在用,对国外用户可以,对国内还不如AWS的实例来的速度。 感谢两位回答。其实我知道,服务器数据同步、资源同步,无论用什么方案,都是要自己做的。暂时DB同步先不需要,资源国内国外都留一份,速度还可以了。

布拉布拉 2019-12-02 01:29:46 0 浏览量 回答数 0

回答

Re又爱又恨的CDN我该拿什么来爱你 说说我用CDN的经历,以及用来解决什么问题吧 起先,我之前的东家在三四线城市,没有主干线路,更别提主干机房或者双线机房了,服务器是托管在电信机房,因为是电信,你懂的,在非电信网络,打开一张HTML页面慢到你想跳楼,就这样,我们开始摸索使用CDN 可以说,我们主要解决以下问题 一、首先我们用CDN主要解决线路加速问题,也就是说可以让非电信线路的用户访问我们的网站也可以得到在电信线路差不多的速度和体验,当然像阿里云的BGP机房就不用担心这个问题了 二、静态资源可以缓存在各个地区的CDN服务器,减少源服务器的流量压力,让用户的浏览器加载速度更快,源服务器只处理动态内容,同时也可以降低源服务器的带宽使用,源服务器集中优势只专门处理动态的业务流量 三、除了解决CDN在线路上的问题,还有解决一个地区差异的问题,比如说跨地区,即使同一线路的用户也有可能访问速度会慢,毕竟经过的节点多,但CDN网络加载动态内容时,节点网络相对来说会快,而静态资源已经在各个CDN服务器,直接返回给用户,访问速度直线提升 四、如果源节点与CDN的IP进行绑定,也就是说,源服务器只接受来自CDN IP流量的时候,或多或少可以减少DDOS攻击流量,如果CDN服务器有做检测的话,那肯定是可以的 再说说,CDN服务器不好的体验或者用不好的时候,是有多惨 一、CDN缓存策略有好几种,要根据自己的程序特性来选择策略,如果没用好,有可能你更新了新的文件或者静态资源时,CDN节点不为所动,还是老文件 二、曾经碰到过CDN服务器在PC访问,速度很正常,但在手机访问时,就慢得要死,当初排查这个排了很久才知道是CDN的问题,但不知道为什么会有这个问题 三、CDN节点,如果在某些地区节点没有备份节点时,一旦挂掉就会导致当地的用户无法访问,严重影响业务 四、严重依赖CDN服务商的技术力量和服务质量,曾经碰到CDN自己内部节点的DNS解析出问题,让我们当时的业务直接瘫痪 五、最重要的一点,CDN的节点要多,节点不多跨地区访问有时候也是有问题 六、有些CDN不支持SDK或者API来控制或清除缓存,这个也是极其难以忍受的,因为某些原因,需要清除所有CDN节点缓存,从源服务器获取新文件 先说这么多了,有想到再补充

天才书生 2019-12-02 01:45:21 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

引用来自“patrick=pk”的答案 引用来自“zTree”的答案 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 @zTree 是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。 这个需要你去改变一下思路了,因为zTree 使用了延迟加载的技术,并不是所有的 节点都在初始化时立刻生成 DOM 的,如果你的需求特殊,建议你不适用 url +target 的方法,而直接利用 onClick 来进行灵活的控制,这样可就容易多了 ###### 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 ######是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。###### 引用来自“zTree”的答案 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 @zTree 是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。 ###### @zTree OK,我试试,多谢。

montos 2020-06-02 12:17:35 0 浏览量 回答数 0

回答

引用来自“patrick=pk”的答案 引用来自“zTree”的答案 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 @zTree 是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。 这个需要你去改变一下思路了,因为zTree 使用了延迟加载的技术,并不是所有的 节点都在初始化时立刻生成 DOM 的,如果你的需求特殊,建议你不适用 url +target 的方法,而直接利用 onClick 来进行灵活的控制,这样可就容易多了 ###### 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 ######是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。###### 引用来自“zTree”的答案 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 @zTree 是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。 ######@zTree OK,我试试,多谢。

kun坤 2020-05-31 21:46:32 0 浏览量 回答数 0

回答

引用来自“patrick=pk”的答案 引用来自“zTree”的答案 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 @zTree 是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。 这个需要你去改变一下思路了,因为zTree 使用了延迟加载的技术,并不是所有的 节点都在初始化时立刻生成 DOM 的,如果你的需求特殊,建议你不适用 url +target 的方法,而直接利用 onClick 来进行灵活的控制,这样可就容易多了 ###### 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 ######是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。###### 引用来自“zTree”的答案 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 @zTree 是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。 ###### @zTree OK,我试试,多谢。

kun坤 2020-06-14 06:29:17 0 浏览量 回答数 0

回答

"<div class=""ref""> 引用来自“patrick=pk”的答案 引用来自“zTree”的答案 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 @zTree 是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。 这个需要你去改变一下思路了,因为zTree 使用了延迟加载的技术,并不是所有的 节点都在初始化时立刻生成 DOM 的,如果你的需求特殊,建议你不适用 url +target 的方法,而直接利用 onClick 来进行灵活的控制,这样可就容易多了 ###### 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 ######是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。###### 引用来自“zTree”的答案 首先很抱歉,我自己并没有在 dwz 中与 ztree 结合做过测试,但是已经有不少朋友问过类似在 dwz 中使用 ztree 的问题,的确还木有看过你这种问题,之前的大部分是用户不熟悉 dwz 的原因导致。 按照你说的情况,我觉得比较奇怪,如果一级节点已经搞定,按道理应该是可以正常结合工作了。 为何二级节点 的target 就无效了呢??对于一级节点/二级节点来说,zTree 本身并没有什么特殊的不同之处。  建议你用 chrome 的调试工具看看,生成的一级节点和二级节点的target 以及 rel 是否都正确? 再就是跟踪一下代码的执行情况。。。  另外,有几个提示之处:是否你的一级节点是初始化后就直接显示了的? 而二级节点要展开后才会显示? 这样的话,一旦你在init 后利用绑定 DOM 的方法控制弹窗,那么肯定是不会影响二级节点的,因为那时候二级节点的 DOM 还木有生成。 @zTree 是的。我默认是只显示了第一级节点,后面的是在调用addDiyDom方法,利用$("#" + treeNode.tId + "_a").attr("target","ajax");去绑定DOM的。怎么样才能在初始化时,就绑定所有的节点呢。 ###### @zTree OK,我试试,多谢。"

montos 2020-05-31 12:04:55 0 浏览量 回答数 0

回答

E-HPC 混合云集群 您可以通过E-HPC创建HPC混合云集群,利用本地的HPC集群向阿里云扩容计算资源,统一调度公共云上资源和用户本地计算节点。 集群的调度结点(头节点),域账号管理节点都在本地,您可以通过以下方式进行本地和云上的节点通信: 云企业网:请参见 什么是云企业网。 物理专线:请参见 申请专线接入。 VPN网关:请参见 什么是VPN网关。 如何搭建VPN网关和建立连接,请参见 配置站点到站点连接。本地网关如果使用strongswan,请参见 strongSwan配置。 注意:本地网关需要允许 UDP 端口 500 和 4500 连入, strongswan 对外监听端口是 500 和 4500。本地网关需要允许域账号系统以及 HPC 集群头结点相关服务监听的端口连入。 环境要求 本地HPC集群管理节点的环境要求如下: 操作系统: Linux CentOS 6.8、6.9 或者 7.2、7.3、7.4 调度集群类型:PBSPro 18.1.1、Slurm 17.2.4 账号管理类型:nis 2.31、ldap 2.4 创建混合云集群 准备工作 搭建好网络连接、VPN、云企业网或者物理专线。 提供本地HPC集群调度节点信息:hostname、ip。 提供本地域账号节点信息: hostname、ip、账号域名 (domain name)。 E-HPC支持如下两种方式创建混合云集群 本地集群已经存在,那么本地集群节点不需要做额外的配置 本地集群还不存在,E-HPC会自动安装配置本地集群调度节点和域账号节点 API调用创建混合云集群 OpenAPI:CreateHybridCluster, 这里假设选择的地域是杭州(regionId:cn-hangzhou)。有关 API 文档,请参见 混合云管理API。 部分参数说明: VpcId:指定以上搭建网络连接相关的VPC。 Nodes:json格式的字符串,内容包含本地集群的调度节点以及账号节点的信息,可以参照以下的例子。 [ {"Role":"AccountManager", "HostName":"account", "IpAddress":"...", "AccountType":"nis"}, {"Role":"ResourceManager", "HostName":"scheduler","IpAddress":"...","SchedulerType":"pbs"} ] 注意: 如果本地调度节点和账号节点为同一个节点,以上 AccountManager 和 ResourceManager 下只需配置 HostName 和 IpAddress 的其中一个。 集群创建成功之后,通过E-HPC控制台可以查看集群基本信息,集群状态处于“安装中”。 本地集群配置 获取集群配置 在混合云集群创建成功之后,通过 API 获取集群配置信息。OpenAPI GetHybridClusterConfig,有关文档请参见 混合云管理API。 配置本地集群节点 登录本地集群调度节点和域账号管理节点,执行如下命令: echo -e "集群配置信息" > /root/ehpc.conf 账号节点和调度节点为两个节点 登录本地域账号管理节点运行如下命令安装配置 E-HPC agent: curl -O http://e-hpc-hangzhou.oss-cn-hangzhou.aliyuncs.com/packages/deploy_ehpc_agent.sh chmod +x deploy_ehpc_agent.sh ./deploy_ehpc_agent.sh -r AccountManager -i -r: # 指定节点角色 -i: # 如果本地集群是已经存在的,指定这个选项就会跳过安装配置域账号服务 登录本地集群调度节点运行如下命令安装配置E-HPC agent: 下载或者从以上域账号节点拷贝部署脚本 curl -O http://e-hpc-hangzhou.oss-cn-hangzhou.aliyuncs.com/packages/deploy_ehpc_agent.sh chmod +x deploy_ehpc_agent.sh ./deploy_ehpc_agent.sh -r ResourceManager -i -r: # 指定节点角色 -i: # 如果本地集群是已经存在的,指定这个选项就会跳过安装配置HPC集群调度服务 账号节点和调度节点为同一个节点 登录本地集群节点运行如下命令安装配置E-HPC agent curl -O http://e-hpc-hangzhou.oss-cn-hangzhou.aliyuncs.com/packages/deploy_ehpc_agent.sh chmod +x deploy_ehpc_agent.sh ./deploy_ehpc_agent.sh -r AccountManager,ResourceManager -i -r: #指定节点角色 -i: #如果本地集群是已经存在的,指定这个选项就会跳过安装配置HPC集群调度服务 本地管理节点部署之后,通过E-HPC控制台可以查看集群基本信息,集群状态会转变为“运行中”。 增加节点 调用 E-HPC OpenAPI AddNodes,请参见 节点管理API。 管理本地节点 E-HPC支持管理部署本地计算节点,将本地计算节点加入到混合云集群,也可以加入到云上的集群,最终统一调度管理。目前支持API方式接入: 增加本地计算节点到E-HPC集群 调用 E-HPC OpenAPI AddLocalNodes,请参见 混合云管理API。 获取新增加的节点配置 调用 E-HPC OpenAPI GetHybridClusterConfig获取该节点配置信息,注意请求参数’Node’必须设置为本地节点的hostname,请参见 混合云管理API。 登录本地计算节点运行如下命令安装配置E-HPC agent: 设置节点配置 echo -e "节点配置信息" > /root/ehpc.conf 下载或者从以上域账号节点拷贝部署脚本 curl -O http://e-hpc-hangzhou.oss-cn-hangzhou.aliyuncs.com/packages/deploy_ehpc_agent.sh chmod +x deploy_ehpc_agent.sh ./deploy_ehpc_agent.sh -r ComputeNode -i -r: # 指定节点角色 -i: # 如果本地计算节点已经安装配置好,指定这个选项就会跳过安装配置HPC集群调度相关服务

1934890530796658 2020-03-23 17:49:08 0 浏览量 回答数 0

回答

MongoDB ACID事务支持 这里要有一定的关系型数据库的事务的概念,不然不一定能理解的了这里说的事务概念。 下面说一说MongoDB的事务支持,这里可能会有疑惑,前面我们在介绍MongoDB时,说MongoDB是一个NoSQL数据库,不支持事务。这里又介绍MongoDB的事务。这里要说明一下MongoDB的事务支持跟关系型数据库的事务支持是两码事,如果你已经非常了解关系型数据库的事务,通过下面一副图对比MongoDB事务跟MySQL事务的不同之处。 MongoDB是如何实现事务的ACID? 1)MongoDB对原子性(Atomicity)的支持 原子性在Mongodb中到底是一个什么概念呢?为什么说支持但又说Mongodb的原子性是单行/文档级原子性,这里提供了一个MongoDB更新语句样例,如下图: MongoDB是如何实现事务的ACID? 更新“username”等于“tj.tang”的文档,更新salary、jobs、hours字段。这里对于这三个字段Mongodb在执行时要么都更新要么都不更新,这个概念在MySQL中可能你没有考虑过,但在MongoDB中由于文档可以嵌套子文档可以很复杂,所以Mongodb的原子性叫单行/文档级原子性。 对于关系型数据库的多行、多文档、多语句原子性目前Mongodb是不支持的,如下情况: MongoDB是如何实现事务的ACID? MongoDB更新条件为工资小于50万的人都把工资调整为50万,这就会牵扯到多文档更新原子性。如果当更新到Frank这个文档时,出现宕机,服务器重启之后是无法像关系型数据库那样做到数据回滚的,也就是说处理这种多文档关系型数据库事务的支持,但MongoDB不支持。那么怎么解决Mongodb这个问题呢?可以通过建模,MongoDB不是范式而是反范式的设计,通过大表和小表可以把相关的数据放到同一个文档中去。然后通过一条语句来执行操作。 2)MongoDB对一致性(consistency)的支持 对于数据一致性来说,传统数据库(单机)跟分布式数据库(MongoDB)对于数据一致性是不太一样的,怎么理解呢?如下图: MongoDB是如何实现事务的ACID? 对于传统型数据库来说,数据一致性主要是在单机上,单机的问题主要是数据进来时的规则检验,数据不能被破坏掉。而在分布式数据库上,因为他们都是多节点分布式的,我们讲的一致性往往就是讲的各个节点之间的数据是否一致。而MongoDB在这点上做的还是不错的,MongoDB支持强一致性或最终一致性(弱一致性),MongoDB的数据一致性也叫可调一致性,什么意思呢?如下图: MongoDB是如何实现事务的ACID? MongoDB的可调一致性,也就是可以自由选择强一致性或最终一致性,如果你的应用场景是前台的方式可以选择强一致性,如果你的应用场景是后台的方式(如报表)可以选择弱一致性。 一致性 上面我们讲到了通过将数据冗余存储到不同的节点来保证数据安全和减轻负载,下面我们来看看这样做引发的一个问题:保证数据在多个节点间的一致性是非常困难的。在实际应用中我们会遇到很多困难,同步节点可能会故障,甚至会无法恢复,网络可能会有延迟或者丢包,网络原因导致集群中的机器被分隔成两个不能互通的子域等等。在NoSQL中,通常有两个层次的一致性:第一种是强一致性,既集群中的所有机器状态同步保持一致。第二种是最终一致性,既可以允许短暂的数据不一致,但数据最终会保持一致。我们先来讲一下,在分布式集群中,为什么最终一致性通常是更合理的选择,然后再来讨论两种一致性的具体实现结节。 关于CAP理论 为什么我们会考虑削弱数据的一致性呢?其实这背后有一个关于分布式系统的理论依据。这个理论最早被Eric Brewer提出,称为CAP理论,尔后Gilbert和Lynch对CAP进行了理论证明。这一理论首先把分布式系统中的三个特性进行了如下归纳: 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。 分区容忍性(P):集群中的某些节点在无法联系后,集群整体是否还能继续进行服务。 而CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。 要保证数据强一致性,最简单的方法是令写操作在所有数据节点上都执行成功才能返回成功,也就是同步概念。而这时如果某个结点出现故障,那么写操作就成功不了了,需要一直等到这个节点恢复。也就是说,如果要保证强一致性,那么就无法提供7×24的高可用性。 而要保证可用性的话,就意味着节点在响应请求时,不用完全考虑整个集群中的数据是否一致。只需要以自己当前的状态进行请求响应。由于并不保证写操作在所有节点都写成功,这可能会导致各个节点的数据状态不一致。 CAP理论导致了最终一致性和强一致性两种选择。当然,事实上还有其它的选择,比如在Yahoo的PNUTS中,采用的就是松散的一致性和弱可用性结合的方法。但是我们讨论的NoSQL系统没有类似的实现,所以我们在后续不会对其进行讨论。 强一致性 强一致性的保证,要求所有数据节点对同一个key值在同一时刻有同样的value值。虽然实际上可能某些节点存储的值是不一样的,但是作为一个整体,当客户端发起对某个key的数据请求时,整个集群对这个key对应的数据会达成一致。下面就举例说明这种一致性是如何实现的。 假设在我们的集群中,一个数据会被备份到N个结点。这N个节点中的某一个可能会扮演协调器的作用。它会保证每一个数据写操作会在成功同步到W个节点后才向客户端返回成功。而当客户端读取数据时,需要至少R个节点返回同样的数据才能返回读操作成功。而NWR之间必须要满足下面关系:R+W>N 下面举个实在的例子。比如我们设定N=3(数据会备份到A、B、C三个结点)。比如值 employee30:salary 当前的值是20000,我们想将其修改为30000。我们设定W=2,下面我们会对A、B、C三个节点发起写操作(employee30:salary, 30000),当A、B两个节点返回写成功后,协调器就会返回给客户端说写成功了。至于节点C,我们可以假设它从来没有收到这个写请求,他保存的依然是20000那个值。之后,当一个协调器执行一个对employee30:salary的读操作时,他还是会发三个请求给A、B、C三个节点: 如果设定R=1,那么当C节点先返回了20000这个值时,那我们客户端实际得到了一个错误的值。 如果设定R=2,则当协调器收到20000和30000两个值时,它会发现数据不太正确,并且会在收到第三个节点的30000的值后判断20000这个值是错误的。 所以如果要保证强一致性,在上面的应用场景中,我们需要设定R=2,W=2 如果写操作不能收到W个节点的成功返回,或者写操作不能得到R个一致的结果。那么协调器可能会在某个设定的过期时间之后向客户端返回操作失败,或者是等到系统慢慢调整到一致。这可能就导致系统暂时处于不可用状态。 对于R和W的不同设定,会导致系统在进行不同操作时需要不同数量的机器节点可用。比如你设定在所有备份节点上都写入才算写成功,既W=N,那么只要有一个备份节点故障,写操作就失败了。一般设定是R+W = N+1,这是保证强一致性的最小设定了。一些强一致性的系统设定W=N,R=1,这样就根本不用考虑各个节点数据可能不一致的情况了。 HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前,写操作是不会返回成功的。也就是说它的W=N,而读操作只需要读到一个值即可,也就是说它R=1。为了不至于让写操作太慢,对多个节点的写操作是并发异步进行的。在直到所有的节点都收到了新的数据后,会自动执行一个swap操作将新数据写入。这个操作是原子性和一致性的。保证了数据在所有节点有一致的值。 最终一致性 像Voldemort,Cassandra和Riak这些类Dynamo的系统,通常都允许用户按需要设置N,R,W三个值,即使是设置成W+R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性,或者是W 3)MongoDB对隔离性(isolation)的支持 在关系型数据库中,SQL2定义了四种隔离级别,分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。但是很少有数据库厂商遵循这些标准,比如Oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ隔离级别。而MySQL支持这全部4种隔离级别。每一种级别都规定了一个事务中所做的修改,哪些在事务内核事务外是可见的,哪些是不可见的。为了尽可能减少事务间的影响,事务隔离级别越高安全性越好但是并发就越差;事务隔离级别越低,事务请求的锁越少,或者保持锁的时间就越短,这也就是为什么绝大多数数据库系统默认的事务隔离级别是RC。 下图展示了几家不同的数据库厂商的不同事物隔离级别。 MongoDB是如何实现事务的ACID? MongoDB在3.2之前使用的是“读未提交”,这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。 下面说说每种隔离级别带来的问题: READ-UNCOMMITTED(读尚未提交的数据) 在这个级别,一个事务的修改,即使没有提交,对其他事务也都是可见的。事务可以读取未提交的数据,这也被称为“脏读(dirty read)”。这个级别会导致很多问题,从性能上来说,READ UNCOMMITTED不会比其他的级别好太多,但却缺乏其他级别的很多好处,除非真的有非常必要的理由,在实际应用中一般很少使用。 READ-COMMITTED(读已提交的数据) 在这个级别,能满足前面提到的隔离性的简单定义:一个事务开始时,只能“看见”已经提交的事务所做的修改。换句话说,一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。这个级别有时候也叫“不可重复读(non-repeatable read)”,因为两次执行同样的查询,可能会得到不一样的结果。 REPEATABLE-READ(可重复读) 在这个级别,保证了在同一个事务中多次读取统一记录的结果是一致的。MySQL默认使用这个级别。InnoDB和XtraDB存储引擎通过多版本并发控制MVCC(multiversion concurrency control)解决了“幻读”和“不可重复读”的问题。通过前面的学习我们知道RR级别总是读取事务开始那一刻的快照信息,也就是说这些数据数据库当前状态,这在一些对于数据的时效特别敏感的业务中,就很可能会出问题。 SERIALIZABLE(串行化) 在这个级别,它通过强制事务串行执行,避免了前面说的一系列问题。简单来说,SERIALIZABLE会在读取的每一行数据上都加锁,所以可能导致大量的超时和锁争用的问题。实际应用中也很少在本地事务中使用SERIALIABLE隔离级别,主要应用在InnoDB存储引擎的分布式事务中。 4)MongoDB对持久性(durability)的支持 对于数据持久性来说,在传统数据库中(单机)的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题,因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。通过下图来看一下传统数据库跟MongoDB对于数据持久性各自所使用的方式。 MongoDB是如何实现事务的ACID? 从上图可以看出,MongoDB同样是使用数据进来先写日志(日志刷盘的速度是非常快)然后在写入到数据库中的这种方式来保证数据的持久性,如果出现服务器宕机,当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging(预写日志系统),而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好,MongoDB的复制默认节点就是三节点以上的复制集群,当数据到达主节点之后会马上同步到从节点上去。

景凌凯 2019-12-02 02:05:12 0 浏览量 回答数 0

问题

创建及配置集群

反向一觉 2019-12-01 21:07:21 1249 浏览量 回答数 0

问题

什么是B+树 6月1日【今日算法】

游客ih62co2qqq5ww 2020-06-01 14:50:52 1 浏览量 回答数 1

问题

【我与阿里云的故事】从陌生到熟悉写给新用户

大脸猫 2019-12-01 21:09:59 14961 浏览量 回答数 6

问题

云服务器简介

爷们儿 2019-12-01 21:54:32 7421 浏览量 回答数 2

回答

说到区块链,我们必然会谈及它的共识机制。不了解区块链的共识机制,就无法理解区块链的真正意义。那么,今日份的区块链的共识机制了解一下? 共识机制是什么? 什么是共识?直取它的字面意思,就是"共同的认识". 人与人是不同的,这种不同不仅体现在身材、长相、能力,更体现在文化、观点、想法、利益诉求等等方面。 共识,简而言之,就是一个群体的成员在某一方面达成的一致意见。 我们了解到,信任是社会运转中的一大痛点,银行有自己的信用体系,过去的金融体系服务于只服务于极少的企业家,因为建立信用体系耗资巨大。后来支付宝有了芝麻信用,信用已经关系到生活的很多方面,信用卡额度、花呗额度,芝麻信用高出国还可以免签。我们正享受着信用给我们带来的便捷。 区块链本质是去中心化,去中心化的核心是共识机制,区块链上的共识机制主要解决由谁来构造区块,以及如何维护区块链统一的问题。 区块链共识机制的目标是使所有的诚实节点保存一致的区块链视图,同时满足两个性质: 1)一致性:所有诚实节点保存的区块链的前缀部分完全相同。 2)有效性:由某诚实节点发布的信息终将被其他所有诚实节点记录在自己的区块链中。 区块链的自信任主要体现于分布于区块链中的用户无须信任交易的另一方,也无须信任一个中心化的机构,只需要信任区块链协议下的软件系统即可实现交易。 共识机制是什么?PoW 、PoS 、DPOW都是什么意思? 共识机制的必要性? 分布式系统中,多个主机通过异步通信方式组成网络集群。在这样的一个异步系统中,需要主机之间进行状态复制,以保证每个主机达成一致的状态共识。错误信息可能出现在异步系统内并不断传播,因此需要在默认不可靠的异步网络中定义容错协议,以确保各主机达成安全可靠的状态共识,这就是共识机制诞生的必要性。 这种自信任的前提是区块链的共识机制(consensus),即在一个互不信任的市场中,要想使各节点达成一致的充分必要条件是每个节点出于对自身利益最大化的考虑,都会自发、诚实地遵守协议中预先设定的规则,判断每一笔记录的真实性,最终将判断为真的记录记入区块链之中。attachments-2018-08-9yY7VRHa5b738e3d96021.jpg 换句话说,如果各节点具有各自独立的利益并互相竞争,则这些节点几乎不可能合谋欺骗你,而当节点们在网络中拥有公共信誉时,这一点体现得尤为明显。区块链技术正是运用一套基于共识的数学算法,在机器之间建立"信任"网络,从而通过技术背书而非中心化信用机构来进行全新的信用创造。 当今区块链的几种共识机制介绍 区块链上的共识机制有多种,但任何一种都不是完美无缺,或者说适用于所有应用场景的。 PoW 工作量证明 整个系统中每个节点为整个系统提供计算能力(简称算力),通过一个竞争机制,让计算工作完成最出色的节点获得系统的奖励,即完成新生成货币的分配,简单理解就是多劳多得,bitcoin、LTC等货币型区块链就应用POW机制。 优点 完全去中心化节点自由进出,算法简单,容易实现破坏系统花费的成本巨大,只要网络破坏者的算力不超过网络总算力的50%,网络的交易状态就能达成一致 缺点 浪费能源,这是最大的缺点区块的确认时间难以缩短,如bitcoin每秒只能做7笔交易,不适合商业应用新的区块链必须找到一种不同的散列算法,否则就会面临bitcoin的算力攻击对节点的性能网络环境要求高容易产生分叉,需要等待多个确认无法达成最终一致性 PoS 权益证明 也称股权证明,类似于你把财产存在银行,这种模式会根据你持有加密货币的数量和时间,分配给你相应的利息。 优点 对节点性能要求低,达成共识时间短 缺点 没有最终一致性,需要检查点机制来弥补最终性 DPOW 委托股权证明 DPOW是 PoS 的进化方案,在常规 PoW和 PoS 中,任何一个新加入的区块,都需要被整个网络所有节点做确认,非常影响效率。 DPoS则类似于现代董事会的投票机制,通过选举代表来进行投票和决策。被选举出的n个记账节点来做新区块的创建、验证、签名和相互监督,这样就极大地减少了区块创建和确认所需要消耗的时间和算力成本。 优点 大幅缩小参与验证和记账节点的数量,可以达到秒级的共识验证 缺点 牺牲了去中心化的概念,不适合公有链 PBFT 实用拜占庭容错 实用拜占庭容错机制是一种采用"许可投票、少数服从多数"来选举领导者并进行记账的共识机制,该共识机制允许拜占庭容错,允许强监督节点参与,具备权限分级能力,性能更高,耗能更低,而且每轮记账都会由全网节点共同选举领导者,允许33%的节点作恶,容错率为33%.实用拜占庭容错特别适合联盟链的应用场景。 优点 会背离中心化,加密货币的存在及奖励机制会产生马太效应,让社区中的穷者更穷,富者更富共识效率高,可实现高频交易 缺点 当系统只剩下33%的节点运行时,系统会停止运行 dBFT 授权拜占庭容错 这种机制是用权益来选出记账人,然后记账人之间通过拜占庭容错算法达成共识。授权拜占庭容错机制最核心的一点,就是最大限度地确保系统的最终性,使区块链能够适用于真正的金融应用场景。 优点 专业化的记账人可以容忍任何类型的错误记账由多人协同完成,每一个区块都有最终性,不会分叉算法的可靠性有严格的数学证明 缺点 当三分之一或以上记账人停止工作后,系统将无法提供服务当三分之一或以上记账人联合作恶,可能会使系统出现分叉 Pool 验证池 基于传统的分布式一致性技术,加上数据验证机制。 优点 不需要加密货币也可以工作,在成熟的分布式一致性算法(Pasox、Raft)基础上,实现秒级共识验证。 缺点 去中心化程度不如bitcoin,更适合多方参与的多中心商业模式。 Paxos 这是一种传统的分布式一致性算法,是一种基于选举领导者的共识机制。领导者节点拥有绝对权限,并允许强监督节点参与,其性能高,资源消耗低。所有节点一般有线下准入机制,但选举过程中不允许有作恶节点,不具备容错性。 Paxos算法中将节点分为三种类型: proposer:提出一个提案,等待大家批准为结案。往往是客户端担任该角色 acceptor:负责对提案进行投票。往往是服务端担任该角色 learner:被告知结案结果,并与之统一,不参与投票过程。可能为客户端或服务端 Paxos 能保证在超过50%的正常节点存在时,系统能达成共识。 瑞波共识机制 瑞波共识算法使一组节点能够基于特殊节点列表形成共识,初始特殊节点列表就像一个俱乐部,要接纳一个新成员,必须由该俱乐部51%的会员投票通过。共识遵循这些核心成员的"51%权利",外部人员则没有影响力。由于该俱乐部由中心化开始,它将一直是中心化的,而如果它开始腐化,股东们什么也做不了。与bitcoin及Peercoin一样,瑞波系统将股东们与其投票权隔开,因此,它比其他系统更中心化。 Peercoin Peercoin(点点币,PPC),混合了POW工作量证明及POS权益证明方式,其中POW主要用于发行货币,未来预计随着挖矿难度上升,产量降低,系统安全主要由POS维护。 在区块链网络中,由于应用场景的不同,所设计的目标各异,不同的区块链系统采用了不同的共识算法。每种共识算法都不是完美的,都有其优点和局限性。 区块链解决了在不可信信道上传输可信信息、价值转移的问题,而共识机制解决了区块链如何分布式场景下达成一致性的问题。 虽然区块链目前还处于发展的早期,行业发展还面临着一些阻碍,但社会已经足够多地认识到区块链的价值,区块链发展的脚步绝不会停滞不前,行业发展也定会找到突破阻碍的方法。

问问小秘 2019-12-02 03:07:12 0 浏览量 回答数 0

问题

什么是 CDN?

青衫无名 2019-12-01 22:01:00 1243 浏览量 回答数 0

回答

参考:https://www.iteblog.com/archives/2530.html分布式和去中心化(Distributed and Decentralized)Cassandra 是分布式的,这意味着它可以运行在多台机器上,并呈现给用户一个一致的整体。事实上,在一个节点上运行 Cassandra 是没啥用的,虽然我们可以这么做,并且这可以帮助我们了解它的工作机制,但是你很快就会意识到,需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行,更为多机架部署进行了优化,甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上,Cassandra 都会收到数据。对于很多存储系统(比如 MySQL, Bigtable),一旦你开始扩展它,就需要把某些节点设为主节点,其他则作为从节点。但 Cassandra 是无中心的,也就是说每个节点都是一样的。与主从结构相反,Cassandra 的协议是 P2P 的,并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理:一文了解 Gossip 协议》。去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样, 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称(server symmetry)。综上所述,Cassandra 是分布式、无中心的,它不会有单点失效,所以支持高可用性。弹性可扩展(Elastic Scalability)可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展,是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器,每台机器提供全部或部分数据,这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。弹性可扩展是指水平扩展的特性,意即你的集群可以不间断的情况下,方便扩展或缩减服务的规模。这样,你就不需要重新启动进程,不必修改应用的查询,也无需自己手工重新均衡数据分布。在 Cassandra 里,你只要加入新的计算机,Cassandra 就会自动地发现它并让它开始工作。高可用和容错(High Availability and Fault Tolerance)从一般架构的角度来看,系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障,从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况,所以它们一般都有硬件冗余,并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统,它必须由多台联网的计算机构成,并且运行于其上的软件也必须能够在集群条件下工作,有设备能够识别节点故障,并将发生故障的中端的功能在剩余系统上进行恢复。Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点,还可以把数据分布到多个数据中心里,从而提供更好的本地访问性能,并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。可调节的一致性(Tuneable Consistency)2000年,加州大学伯克利分校的 Eric Brewer 在 ACM 分布式计算原理会议提出了著名的 CAP 定律。CAP 定律表明,对于任意给定的系统,只能在一致性(Consistency)、可用性(Availability)以及分区容错性(Partition Tolerance)之间选择两个。关于 CAP 定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及 BASE 理论》以及《一篇文章搞清楚什么是分布式系统 CAP 定理》。所以 Cassandra 在设计的时候也不得不考虑这些问题,因为分区容错性这个是每个分布式系统必须考虑的,所以只能在一致性和可用性之间做选择,而 Cassandra 的应用场景更多的是为了满足可用性,所以我们只能牺牲一致性了。但是根据 BASE 理论,我们其实可以通过牺牲强一致性获得可用性。Cassandra 提供了可调节的一致性,允许我们选定需要的一致性水平与可用性水平,在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前,必须阻塞系统。这是通过设置副本因子(replication factor)来调节与之相对的一致性级别。通过副本因子(replication factor),你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数(注意,更新包括所有增加、删除和更新操作)。客户端每次操作还必须设置一个一致性级别(consistency level)参数,这个参数决定了多少个副本写入成功才可以认定写操作是成功的,或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。所以,如果需要的话,你可以设定一致性级别和副本因子相等,从而达到一个较高的一致性水平,不过这样就必须付出同步阻塞操作的代价,只有所有节点都被更新完成才能成功返回一次更新。而实际上,Cassandra 一般都不会这么来用,原因显而易见(这样就丧失了可用性目标,影响性能,而且这不是你选择 Cassandra 的初衷)。而如果一个客户端设置一致性级别低于副本因子的话,即使有节点宕机了,仍然可以写成功。总体来说,Cassandra 更倾向于 CP,虽然它也可以通过调节一致性水平达到 AP;但是不推荐你这么设置。面向行(Row-Oriented)Cassandra 经常被看做是一种面向列(Column-Oriented)的数据库,这也并不算错。它的数据结构不是关系型的,而是一个多维稀疏哈希表。稀疏(Sparse)意味着任何一行都可能会有一列或者几列,但每行都不一定(像关系模型那样)和其他行有一样的列。每行都有一个唯一的键值,用于进行数据访问。所以,更确切地说,应该把 Cassandra 看做是一个有索引的、面向行的存储系统。Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段,还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中,不必进行长达数月的预先分析。对于使用 Cassandra 的应用,如果业务发生变化了,只需要在运行中增加或删除某些字段就行了,不会造成服务中断。当然, 这不是说你不需要考虑数据。相反,Cassandra 需要你换个角度看数据。在 RDBMS 里, 你得首先设计一个完整的数据模型, 然后考虑查询方式, 而在 Cassandra 里,你可以首先思考如何查询数据,然后提供这些数据就可以了。灵活的模式(Flexible Schema)Cassandra 的早期版本支持无模式(schema-free)数据模型,可以动态定义新的列。 无模式数据库(如 Bigtable 和 MongoDB)在访问大量数据时具有高度可扩展性和高性能的优势。 无模式数据库的主要缺点是难以确定数据的含义和格式,这限制了执行复杂查询的能力。为了解决这些问题,Cassandra 引入了 Cassandra Query Language(CQL),它提供了一种通过类似于结构化查询语言(SQL)的语法来定义模式。 最初,CQL 是作为 Cassandra 的另一个接口,并且基于 Apache Thrift 项目提供无模式的接口。 在这个过渡阶段,术语“模式可选”(Schema-optional)用于描述数据模型,我们可以使用 CQL 的模式来定义。并且可以通过 Thrift API 实现动态扩展以此添加新的列。 在此期间,基础数据存储模型是基于 Bigtable 的。从 3.0 版本开始,不推荐使用基于 Thrift API 的动态列创建的 API,并且 Cassandra 底层存储已经重新实现了,以更紧密地与 CQL 保持一致。 Cassandra 并没有完全限制动态扩展架构的能力,但它的工作方式却截然不同。 CQL 集合(比如 list、set、尤其是 map)提供了在无结构化的格式里面添加内容的能力,从而能扩展现有的模式。CQL 还提供了改变列的类型的能力,以支持 JSON 格式的文本的存储。因此,描述 Cassandra 当前状态的最佳方式可能是它支持灵活的模式。高性能(High Performance)Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能,并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器,存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现,在一个非常普通的工作站上,Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器,你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。

封神 2019-12-02 02:00:50 0 浏览量 回答数 0

问题

Blink计算引擎 【精品问答集锦】

管理贝贝 2019-12-01 20:28:13 18841 浏览量 回答数 2

问题

我想用阿里云

mod 2019-12-01 21:47:31 4260 浏览量 回答数 5

回答

MaxCompute 向用户提供了完善的数据导入方案以及多种经典的分布式计算模型,能够更快速的解决用户海量数据计算问题,有效降低企业成本,并保障数据安全提交一个SQL语句,发送 RESTful 请求给HTTP服务器HTTP 服务器做用户认证。认证通过后,请求就会以 Kuafu通信协议方式发送给 Worker。Worker判断该请求作业是否需要启动Fuxi Job。如果不需要,本地执行并返回结果。如果需要,则生成一个 instance, 发送给 Scheduler。Scheduler把instance信息注册到 OTS,将其状态置成 Running。Scheduler 把 instance 添加到 instance 队列。Worker把 Instance ID返回给客户端。倾斜问题则一般是数据本身的问题,常见的数据倾斜是怎么造成的?Shuffle的时候,将各个节点上相同的key拉取到某个节点的一个task进行处理,比如按照key进行聚合或join等操作,如果某个key对应的数据量特别大的话,就会发生数据倾斜现象。数据倾斜就成为了整个task运行时间的短板。触发shuffle的常见算子:distinct、groupBy、join等。要解决数据倾斜的问题,首先要定位数据倾斜发生在什么地方,首先是哪个stage,直接在D2 UI上看就可以,查看数据是否倾斜了logview--odps task--detail--stage--longtail根据stage日志,判断出数据倾斜发生在哪个算子上。根据倾斜发生的阶段,我们又可以把它们分为map倾斜,reduce倾斜,join倾斜通常来说,对于倾斜现象,我们首先查看导致数据倾斜的key的数据分布情况,接下来大概有几种处理方案:1:过滤数据过滤掉某些脏数据,比如说是否可以去掉null,去掉某些条件对应的值2:加大并行度给任务添加处理资源,加大instance的数量,暴力3:对数据进行拆分,分而治之如果大表join小表,我们可以用mapjoin,将小表cache进内存二次分发,加上随机前缀(数据膨胀),拆分数据集为热点+非热点再进一步处理大表join超大表,还可以考虑bloomfilter4:组合使用上述方法,组合使用5:修改业务实在没有进步空间,从业务上过滤数据

萧宇@52 2019-12-01 23:54:35 0 浏览量 回答数 0

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

问题

E-MapReduceHue 使用说明是什么?

nicenelly 2019-12-01 21:21:44 735 浏览量 回答数 0

问题

大流量高并发站点终极优化方案,十分钟让网站性能提升10倍

淹死的魚 2019-12-01 22:05:38 28087 浏览量 回答数 14

回答

所谓区块链,即为一个个用这样的计算力保障的数据块链条。从第一块开始,每一个区块依照一定规则收集数据,然后将这些数据附上一个值,使得形成的数据块经过类似的单向函数计算后的结果落到一定范围内。通过估算全网的算力以及控制结果范围的大小,来保障符合要求数据块在足够长的时间内才能被找到。这个计算结果会被下一个区块包含,而这样形成的链式数据结构则称为区块链。 每一个小账本被称为区块,每一个不同的区块链协议(产生不同的加密货币)都会规定每一个区块的大小(最初比特币为1M)账本组成区块,区块构成链表,区块的头包含前一块的哈希值,这就是区块链。如此一来,任何人就不能随意修改其中的内容,或者交换顺序。如果你这么做,意味着你需要重新计算所有的特殊数字。 规定,允许世界上的每一个人建造区块。每一个新建区块的人(找到了这个特殊数字 - SHA256值有30个零)都能获得奖励,对于新建区块的这部分人(矿工)来说: 没有发送者信息,不需要签名 每一个新区块都会给整个币种增加新的虚拟(加密)货币 新建区块的过程又被称为"挖矿":需要大量工作量并且可以向整个经济体注入新的货币 挖矿的工作是:接受交易信息,建造区块,把区块广播出去,然后得到新的钱作为奖励 对每个矿工来说,每个区块就像一个小彩票,所有人都在拼命快速猜数字,直到有一个幸运儿找到了一个特殊数字,使得整个区块的哈希值开头有许多个零,就能得到奖励。我记得有一个知乎答主给了一个形象的比喻,区块链就像一个拥有貌美如花女儿(区块)的国王,有很多的青年翘首以盼,而国王的方法是出了一道很难得题目让所有的青年计算(学习改变人生),谁算的快(在计算哈希值过程也可能是运气好)就能抱得美人归 对于想用这个系统来收付款的用户来说,他们不需要收听所有的交易,而只要收听矿工们广播出来的区块,然后更新到自己保存的区块链中就可以了 "区块"也可以想象为一个盒子,区块里放着一些数字货币以及一张小纸条,小纸条上记录了这十分钟内产生的那唯一一笔交易信息, 比如说--"小A转账给了小B100元";当然,这段信息肯定是被加密处理过的,为的就是保证只有小A和小B(通过他们手上的钥匙)才有能力解读里面真正的内容。 这个神奇的区块被创造出来之后,很快被埋在了地底下,至于埋在哪里?没有一个人不知道,需要所有计算机节点一起参与进来掘地三尺后才有可能找到(找到一个有效的工作量证明)。显然,这是一件工作量巨大、成果随机的事件。但是呢,对于计算机节点来说,一旦从地底下挖出这个区块,他将获得区块内价值不菲的数字货币,以及"小A转账给了小B100元"过程中小A所支付的小费。同时,对于这个节点来说,也只有他才有权利真正记录小纸条里的内容,这是一份荣耀,而其他节点相当于只能使用它的复制品,一个已经没有数字货币加持的副本。当然这个神奇的区块还有一些其他很特别的地方, 可以将计算机节点从地底下挖出区块的过程叫做「挖矿」,刚才说了,这是一件工作量巨大、运气成分较多、但收益丰厚的事儿。来自中国上海浦东新区张衡路上的一个节点突然跳出来很兴奋的说:" 我挖到区块了!里面的小纸条都是有效的!奖励归我!" .虽然此刻张衡路节点已经拿到了数字货币,但对于其他计算机节点来说,因为这里面还涉及到其他一些利益瓜葛,他们不会选择默认相信张衡路节点所说的话;基于陌生节点彼此不信任的原则,他们拿过张衡路节点所谓挖到的区块(副本),开始校验区块内的小纸条信息是否真实有效等等。在区块链世界里,节点们正是通过校验小纸条信息的准确性,或间接或直接判断成功挖出区块的节点是否撒谎。(如何定义小纸条信息真实有效,后面会讲解,这里暂不做赘述)。在校验过程中,各个节点们会直接通过下面两个行为表达自己对张衡路节点的认同(准确无误)和态度:停止已经进行了一半甚至80%的挖矿进程;将张衡路节点成功挖出的区块(副本)追加到自己区块链的末尾。你可以稍微有点困惑:停止可能已经执行了80%的挖矿行为,那之前80%的工作不是就白做了嘛?!然后,区块链的末尾又是个什么鬼东西?对于第一个困惑。 我想说,你说的一点没错,但是没办法,现实就是这么残酷,即便工作做了80%,那也得放弃,这80%的工作劳苦几乎可以视为无用功,绝对的伤财劳众。第二个困惑,区块链和区块链的末尾是什么鬼?这里因为事先并没有讲清楚,但是你可以简单想象一下:区块是周期性不断的产生和不断的被挖出来,一个计算机节点可能事先已经执行了N次"从别人手上拿过区块 -> 校验小纸条有效性"的流程,肯定在自己的节点上早已经存放了N个区块,这些区块会按照时间顺序整齐的一字排列成为一个链状。没错,这个链条,就是你一直以来认为的那个区块链。如果你还是不能够理解,没关系,文章后面还会有很多次机会深入研究。 进入到区块内更微观的世界里一探究竟,看看小纸条到底是怎么一回事,它的产生以及它终其一生的使命:发起交易的时候,发起人会收到一张小纸条,他需要将交易记录比如说"盗盗转账给张三40元"写在纸上。说来也神奇,当写完的那一刹那,在小纸条的背面会自动将这段交易记录格式化成至少包含了"输入值"和"输出值"这两个重要字段;"输入值"用于记录数字货币的有效来源,"输出值"记录着数字货币发往的对象。刚刚创建的小纸条立马被标记成为"未确认"的小纸条。从地下成功挖出区块并最终连接到区块链里的小纸条一开始会被标记为"有效". 若这条有效的小纸条作为其他交易的输入值被使用,那么,这个有效的小纸条很快会被标记为"无效".因为各种原因,区块从链上断开、丢弃,曾经这个区块内被标记为"有效"的小纸条会被重新标记为"未确认".区块链里面没有账户余额的概念,你真正拥有的数字资产实际上是一段交易信息;通过简单的加减法运算获知你数字钱包里的余额。上面的1、2、3仅仅作为结论一开始强行灌输给你的知识点,其中有几个描述可能会有点绕,让你觉得云里雾里,只有了解整体区块链你才能更全面认知其中奥妙。 区块容量,比特币从被创建时,或者说源代码中规定了,区块容量是1M.最初设计成1M的原因一方面,防止DOS攻击。另一方面,当年中本聪在创建区块链的时候的容量是32M,但是他通过一个说明为"Clear up"这样毫不起眼的Commit把区块容量改成了1M,为防止区块链体积增长过快,为区块容量这个问题添加了些神秘色彩。1M的容量意味着比特币最大的处理交易数量在约2400(486882区块1034.39的大小很接近了)。

问问小秘 2019-12-02 03:07:11 0 浏览量 回答数 0

回答

回 1楼梦丫头的帖子 用户通过访问web 网站下载文件【保存在OSS上的文件】 ------------------------- 回 3楼jesuiszb的帖子 是用户通过网页访问的文件下载需求,下载到自己本地,还有其他的方案吗? ------------------------- 回 5楼jesuiszb的帖子 php 多文件一次打包下载有搞过吗?或者有什么好的解决方案吗? ------------------------- 回 7楼jesuiszb的帖子 谢谢你的方案。现在是网站有一组一组的文件,可以单独下载也可以针对每组点击一键打包下载。文件想存贮在OSS上(如果存贮在php同服务器上比较好解决),现在正在寻找解决方案,还没确定到底怎么做。工单询问阿里云暂时OSS不提供打包服务,也只能自己找解决方案了。 单文件下载比较简单,直接从OSS下载就行了,主要是多文件打包下载:这种情况如果先一次下载到php网站服务器》然后在服务器完成打包》再让用户下载,这个流程可能耗时比较长。目前还在寻找其他解决方案,如果你有更好的方案也可一起讨论。再次谢过! ------------------------- Re文件存贮在阿里云的OSS,PHP怎么实现多文件打包下载? 或者把“文件打包操作”放在某个节点去完成,下载前(上传完成)、下载中(点击下载触发)等节点,完成一次打包,再次下载可直接下载打包好的多文件,需要考虑变化性和耗时等因素。 ------------------------- 回 10楼寒喵的帖子 恩,挺好的建议,谢谢。暂时打包文件操作只能放在ECS了,就看这个操作放在哪一步节点上了

nbeliu 2019-12-02 00:33:05 0 浏览量 回答数 0

回答

您可以通过阿里云RDS管理控制台或API创建RDS实例。本文介绍如何通过控制台创建RDS MySQL实例。 其他引擎创建实例请参见: 创建RDS SQL Server实例 创建RDS PostgreSQL实例 创建RDS PPAS实例 创建RDS MariaDB实例 除了新版本的创建实例页面,您也可以切换回旧版创建实例页面。操作详情请参见: 创建RDS实例(新版) 创建RDS实例(旧版) 优惠活动 首购折扣价:首次购买RDS MySQL享受折扣价。详情请参见优惠活动。 计费说明 关于实例计费说明,请参见计费方式。 前提条件 已注册阿里云账号。具体操作请参见注册阿里云账号。 若您要创建按量付费的实例,请确保您的阿里云账号的余额大于等于100元。 注意事项 包年包月实例无法转为按量付费实例。 按量付费实例可以转为包年包月实例,请参见按量付费转包年包月。 同一个主账号,最多可以创建30个按量付费的RDS实例。如需提高此限额,请提交工单申请。 创建RDS实例(新版) 进入RDS实例创建页面。 说明 您也可以在当前创建RDS实例页面上方单击返回旧版切换到旧版创建RDS实例页面。 设置以下参数。 类别 说明 计费方式 包年包月:属于预付费,即在新建实例时需要支付费用。适合长期需求,价格比按量付费更实惠,且购买时长越长,折扣越多。 按量付费:属于后付费,即按小时扣费。适合短期需求,用完可立即释放实例,节省费用。 地域 实例所在的地域,即实例所在的地理位置。 购买后无法更换地域。 请根据目标用户所在的地理位置就近选择地域,提升用户访问速度。 请确保RDS实例与需要连接的ECS实例创建于同一个地域,否则它们无法通过内网互通,只能通过外网互通,无法发挥最佳性能。 类型 数据库引擎的类型和版本,这里选择MySQL。 当前支持MySQL 5.5、5.6、5.7、8.0。 说明 不同地域支持的数据库类型不同,请以实际界面为准。 系列 基础版:单节点,计算与存储分离,性价比高。 高可用版:一个主节点和一个备节点,经典高可用架构。 三节点企业版(原金融版):一个主节点和两个备节点,位于同一地域的三个不同的可用区,提供金融级可靠性。 说明 不同地域和数据库版本支持的系列不同,请以实际界面为准。关于各个系列的详细介绍,请参见产品系列概述。 存储类型 本地SSD盘:与数据库引擎位于同一节点的SSD盘。将数据存储于本地SSD盘,可以降低I/O延时。 ESSD云盘:增强型(Enhanced)SSD云盘,是阿里云全新推出的超高性能云盘产品。ESSD云盘基于新一代分布式块存储架构,结合25GE网络和RDMA技术,为您提供单盘高达100万的随机读写能力和更低的单路时延。ESSD云盘分为如下三类: ESSD云盘:PL1性能级别的ESSD云盘。 ESSD PL2云盘:相比PL1,PL2性能级别的ESSD云盘大约可提升2倍IOPS和吞吐量。 ESSD PL3云盘:相比PL1,PL3性能级别的ESSD云盘最高可提升20倍IOPS、11倍吞吐量,适合对极限并发I/O性能要求极高、读写时延极稳定的业务场景。 SSD云盘:基于分布式存储架构的弹性块存储设备。将数据存储于SSD云盘,即实现了计算与存储分离。 更多信息,请参见存储类型。 可用区 可用区是地域中的一个独立物理区域,主节点可用区指主实例所在可用区,备节点可用区指备实例所在可用区。 您可以设置实例为单可用区部署或多可用区部署: 单可用区部署指主节点可用区和备节点可用区都处于相同可用区。 多可用区部署指主节点可用区和备节点可用区处于不同可用区,此时您只需要选择主节点可用区,系统会自动选择备节点可用区。 相比单可用区部署,多可用区部署能提供可用区级别的容灾,建议您使用多可用区部署。 可用区 实例规格 入门级:通用型的实例规格,独享被分配的内存和I/O资源,与同一服务器上的其他通用型实例共享CPU和存储资源。 企业级:独享或独占型的实例规格。独享型指独享被分配的CPU、内存、存储和I/O资源。独占型是独享型的顶配,独占整台服务器的CPU、内存、存储和I/O资源。 说明 每种规格都有对应的CPU核数、内存、最大连接数和最大IOPS。详情请参见主实例规格列表。 存储空间 存储空间包括数据空间、系统文件空间、Binlog文件空间和事务文件空间。调整存储空间时最小单位为5GB。 说明 部分本地SSD盘的存储空间大小与实例规格绑定,ESSD/SSD云盘不受此限制。详情请参见主实例规格列表。 单击下一步:网络和资源组。 设置以下参数。 类别 说明 网络类型 经典网络:传统的网络类型。 专有网络:也称为VPC(Virtual Private Cloud)。VPC是一种隔离的网络环境,安全性和性能均高于传统的经典网络。选择专有网络时您需要选择对应的VPC和主节点交换机。 说明 请确保RDS实例与需要连接的ECS实例网络类型一致(如果选择专有网络,还需要保证VPC一致),否则它们无法通过内网互通。 存储引擎 设置实例的默认存储引擎。当前仅MySQL 8.0高可用版(本地SSD盘)实例支持此选项。 关于阿里自研的X-Engine引擎详情请参见X-Engine简介。 说明 X-Engine兼容InnoDB,而且拥有更好的性能表现,建议您使用X-Engine作为默认存储引擎。 参数模板 设置实例参数模板。当前仅高可用版(本地SSD盘)实例支持此选项。 说明 您可以选择系统参数模板或自定义参数模板,详情请参见使用参数模板。 时区 设置实例时区。当前仅本地SSD盘实例支持此选项。 表名大小写 设置实例表名是否区分大小写。当本地数据库区分大小时,您可以选择区分大小写,便于您迁移数据。当前仅本地SSD盘实例支持此选项。 资源组 实例所属的资源组。 单击下一步:确认订单。 确认参数配置,选择购买量和购买时长(仅包年包月实例),勾选服务协议,单击去支付完成支付。 创建RDS实例(旧版) 进入旧版RDS实例创建页面。 选择计费方式。 按量付费:属于后付费,即按小时扣费。适合短期需求,用完可立即释放实例,节省费用。 包年包月:属于预付费,即在新建实例时需要支付费用。适合长期需求,价格比按量付费更实惠,且购买时长越长,折扣越多。 设置以下参数。 参数 说明 地域 实例所在的地理位置。购买后无法更换地域。 请根据目标用户所在的地理位置就近选择地域,提升用户访问速度。 请确保RDS实例与需要连接的ECS实例创建于同一个地域,否则它们无法通过内网互通,只能通过外网互通,无法发挥最佳性能。 资源组 实例所属的资源组。 数据库类型 即数据库引擎的类型,这里选择MySQL。 说明 不同地域支持的数据库类型不同,请以实际界面为准。 版本 指MySQL的版本。当前支持MySQL 5.5、5.6、5.7、8.0。 说明 不同地域所支持的版本不同,请以实际界面为准。 系列 基础版:单节点,计算与存储分离,性价比高。 高可用版:一个主节点和一个备节点,经典高可用架构。 三节点企业版(原金融版):一个主节点和两个备节点,位于同一地域的三个不同的可用区,提供金融级可靠性。仅4个地域提供三节点企业版实例:华东1、华东2、华南1、华北2。 说明 不同数据库版本支持的系列不同,请以实际界面为准。关于各个系列的详细介绍,请参见产品系列概述。 存储类型 本地SSD盘:与数据库引擎位于同一节点的SSD盘。将数据存储于本地SSD盘,可以降低I/O延时。 SSD云盘:基于分布式存储架构的弹性块存储设备。将数据存储于SSD云盘,即实现了计算与存储分离。 说明 SSD云盘支持云盘加密,能够最大限度保护您的数据安全,您的业务和应用程序无需做额外的改动。详情请参见云盘加密。 ESSD云盘:增强型(Enhanced)SSD云盘,是阿里云全新推出的超高性能云盘产品。ESSD云盘基于新一代分布式块存储架构,结合25GE网络和RDMA技术,为您提供单盘高达100万的随机读写能力和更低的单路时延。 更多信息,请参见存储类型。 密钥 云盘加密所使用的的密钥。密钥的创建请参见管理密钥。 可用区 可用区是地域中的一个独立物理区域,不同可用区之间没有实质性区别。您可以选择将RDS实例的主备节点创建在同一可用区或不同可用区。 相比单可用区,多可用区能提供可用区级别的容灾。 网络类型 经典网络:传统的网络类型。 专有网络(推荐):也称为VPC(Virtual Private Cloud)。VPC是一种隔离的网络环境,安全性和性能均高于传统的经典网络。 说明 请确保RDS实例与需要连接的ECS实例网络类型一致,否则它们无法通过内网互通。 规格 每种规格都有对应的CPU核数、内存、最大连接数和最大IOPS。详情请参见主实例规格列表。 RDS实例有以下规格族: 通用型:独享被分配的内存和I/O资源,与同一服务器上的其他通用型实例共享CPU和存储资源。 独享型:独享被分配的CPU、内存、存储和I/O资源。 独占物理机型:是独享型的顶配,独占整台服务器的CPU、内存、存储和I/O资源。 例如,8核32GB是通用型实例规格,8核32GB(独享套餐)是独享型实例规格,30核220GB(独占主机)是独占物理机型实例规格。 存储空间 该存储空间包括数据空间、系统文件空间、Binlog文件空间和事务文件空间。 设置购买时长(仅针对包年包月实例)和实例数量,然后单击右侧的立即购买。 说明 购买包年包月实例时,可以勾选自动续费,系统将根据您的购买时长进行自动续费。例如,您购买3个月的实例并勾选自动续费,则每次自动续费时会缴纳3个月的费用。 对于包年包月实例,您也可以单击加入购物车将实例加入到购物车中,最后单击购物车进行结算。 在订单确认页面,勾选相关协议,根据提示完成支付。 下一步 在控制台左上角,选择实例所在的地域即可查看到刚刚创建的实例。选择地域 创建实例后,您需要设置白名单和创建账号,如果是通过外网连接,还需要申请外网地址。然后就可以连接实例。 如果连接实例失败,请参见解决无法连接实例问题。 常见问题 为什么创建实例后无反应,实例列表也看不到创建中的实例? 看不到创建中的实例可能有如下两个原因: 地域错误 可能您所在地域和您创建实例时选择的地域不一致。您可以在页面左上角切换地域。 选择地域 可用区内资源不足 由于可用区资源是动态分配的,可能您下单后可用区内资源不足,所以会创建失败,建议您更换可用区重试。创建失败您可以在订单列表里看到退款。 如何授权子账号管理RDS实例? 答:请参见云数据库 RDS 授权。 相关API API 描述 CreateDBInstance 创建RDS实例。 操作视频 RDS实例创建

游客yl2rjx5yxwcam 2020-03-09 10:46:09 0 浏览量 回答数 0

问题

SLB疑问解答综合帖导航(持续更新……)

sunfei 2019-12-01 22:01:55 7796 浏览量 回答数 1

问题

SLB疑问解答综合帖导航(持续更新……)

sunfei 2019-12-01 21:56:48 9945 浏览量 回答数 8

问题

SLB帮助文档汇总,找茬补充有奖励哦,持续更新中

否极泰来 2019-12-01 21:06:10 10564 浏览量 回答数 1

回答

拿PHP提供的session来说,默认使用的是文件存储的方式,会话文件就保存在当前的服务器,一般是/tmp下: session.save_handler=files session.save_path=/tmp PHP的会话机制会给客户端设置一个cookie用来保存sesseion_id,对应服务器上的会话文件/tmp/sess_ sesseion_id 把这些session绑定在本机的Web应用放到 Nginx的upstream应用集群应该是不合适的,就算 设置ip_hash让固定IP只访问一个后端, 但如果客户端IP在会话中改变,那就有可能连上后端其他的服务器,这样会导致找不到会话. 还有如果这台后端服务器宕机,那用户的会话也会丢失. 所以最好还是自己用cookie实现一套适合自己的session机制,比如用mysql内存表或者memcached来保存cookie对应的会话数据,非关键和不敏感的数据直接设置cookie保存到客户端,这样会话数据就不会存储在具体的应用服务器上,方便了使用Nginx的 upstream进行php-fpm应用服务器集群扩展. 引用来自“eechen”的答案 拿PHP提供的session来说,默认使用的是文件存储的方式,会话文件就保存在当前的服务器,一般是/tmp下: session.save_handler=files session.save_path=/tmp PHP的会话机制会给客户端设置一个cookie用来保存sesseion_id,对应服务器上的会话文件/tmp/sess_ sesseion_id 把这些session绑定在本机的Web应用放到 Nginx的upstream应用集群应该是不合适的,就算 设置ip_hash让固定IP只访问一个后端, 但如果客户端IP在会话中改变,那就有可能连上后端其他的服务器,这样会导致找不到会话. 还有如果这台后端服务器宕机,那用户的会话也会丢失. 所以最好还是自己用cookie实现一套适合自己的session机制,比如用mysql内存表或者memcached来保存cookie对应的会话数据,非关键和不敏感的数据直接设置cookie保存到客户端,这样会话数据就不会存储在具体的应用服务器上,方便了使用Nginx的 upstream进行php-fpm应用服务器集群扩展. 回复 @eechen:同样多谢大神,我刚开始学习nginx,太复杂的话反而我怕造成其他问题,ip_hase这样的方式也算是适合我们想在的系统环境了,不是完全“均衡”的负载,但是也能分担单个节点压力,存在节点的宕机风险导致部分用户无法使用,也好过现在单个节点承受的风险,是不是这个道理哈~~这个你最好问下Tengine作者 @shudu,看看有没有可行的方法。把内网特定的IP段用Nginx分流到后端Tomcat上,可以试着这样干: server{if($remote_addr=192.168.0.20){location~\.(jsp|do)${proxy_set_headerX-Real-IP$remote_addr;proxy_set_headerX-Forwarded-For$remote_addr;proxy_set_headerHost$host;proxy_passhttp://192.168.0.1:8080;}}} 把来自192.168.0.20的jsp和do请求proxy给后面192.168.0.1的服务器。 条件$remote_addr 那里可以用正则匹配一个IP段,这样应该就可以把该IP段的动态请求导到指定的Tomcat服务器上。后台系统是java吗?回复 @夏天198801:不一定非要序列化,可以后台转换成json,存入memcached,取出json再映射成session回复 @屁屁果:额,这个之前试过,但是后来发现tomcat里面有一个工程的session没有序列化,做不了session共享,上面描述问题里面我也提到过了,我们的开发不好协调,找他们做session序列化没做好回复 @夏天198801:可以扩展tomcat,实现容器级别的session共享,就和应用没有关系了http://www.9iu.org/2011/11/25/tomcat-memcached-session-sso.html是啊,后台是java,容器是tomcat 可以把session托管到memcache或者redis嘛 推荐你使用Tengine: 1、使用Tengine的consistent_hash功能,以你的登录的cookie为key,这样的话一个固定的用户(登录cookie值)可以hash到一台固定的机器上。 2、如果没有登录(即没有登录cookie),则使用round-robin方式(默认的负载均衡方式)。 3、你可以使用if来判断cookie值是否为空。兼容从nginx转tengine有无什么限制?都兼容么?赞一个mark客户端服务器session是靠浏览器cookie维持的,每次去请求都会带一个参数SESSIONID。so...只要把nginx的分发策略设置为根据cookie中的SESSIONID来分发。可以满足你的需求。只要第一次登陆(不管ip是否登陆过)都会走负载,重新分配节点;如果已经访问过(带cookie)则可以保证分配到同一节点。QQ:875881559欢迎交流

爱吃鱼的程序员 2020-06-22 14:22:45 0 浏览量 回答数 0

回答

一 容器 在学习k8s前,首先要了解和学习容器概念和工作原理。 什么是容器? 容器是一种轻量级、可移植、自包含的软件打包技术,使应用程序可以在几乎任何地方以相同的方式运行。开发人员在自己笔记本上创建并测试好的容器,无需任何修改就能够在生产系统的虚拟机、物理服务器或公有云主机上运行。 容器的优势 容器使软件具备了超强的可移植能力。 对于开发人员 – Build Once, Run Anywhere 容器意味着环境隔离和可重复性。开发人员只需为应用创建一次运行环境,然后打包成容器便可在其他机器上运行。另外,容器环境与所在的 Host 环境是隔离的,就像虚拟机一样,但更快更简单。 对于运维人员 – Configure Once, Run Anything 只需要配置好标准的 runtime 环境,服务器就可以运行任何容器。这使得运维人员的工作变得更高效,一致和可重复。容器消除了开发、测试、生产环境的不一致性。 Docker概念 “Docker” 一词指代了多个概念,包括开源社区项目、开源项目使用的工具、主导支持此类项目的公司 Docker Inc. 以及该公司官方支持的工具。技术产品和公司使用同一名称,的确让人有点困惑。 我们来简单说明一下: IT 软件中所说的 “Docker” ,是指容器化技术,用于支持创建和使用容器。 开源 Docker 社区致力于改进这类技术,并免费提供给所有用户,使之获益。 Docker Inc. 公司凭借 Docker 社区产品起家,它主要负责提升社区版本的安全性,并将技术进步与广大技术社区分享。此外,它还专门对这些技术产品进行完善和安全固化,以服务于企业客户。 借助 Docker,您可将容器当做轻巧、模块化的虚拟机使用。同时,您还将获得高度的灵活性,从而实现对容器的高效创建、部署及复制,并能将其从一个环境顺利迁移至另一个环境,从而有助于您针对云来优化您的应用。 Docker有三大核心概念: 镜像(Image)是一个特殊的文件系统,提供容器运行时所需的程序、库、配置等,构建后不会改变 容器(Container)实质是进程,拥有自己独立的命名空间。 仓库(Repository)一个仓库可以包含多个标签(Tag),每个标签对应一个镜像 容器工作原理 Docker 技术使用 Linux 内核和内核功能(例如 Cgroups 和 namespaces)来分隔进程,以便各进程相互独立运行。这种独立性正是采用容器的目的所在;它可以独立运行多种进程、多个应用,更加充分地发挥基础设施的作用,同时保持各个独立系统的安全性。 二 Kubernetes入门知识指南 Kubernets的知识都可以在官方文档查询,网址如下: https://kubernetes.io/zh/docs/home/ Kubernetes基础知识 Kubernetes是什么? Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。 为什么需要 Kubernetes 容器是打包和运行应用程序的好方式。在生产环境中,您需要管理运行应用程序的容器,并确保不会停机。例如,如果一个容器发生故障,则需要启动另一个容器。如果由操作系统处理此行为,会不会更容易? Kubernetes 为您提供: 服务发现和负载均衡 Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果到容器的流量很大,Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。 存储编排 Kubernetes 允许您自动挂载您选择的存储系统,例如本地存储、公共云提供商等。 自动部署和回滚 您可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态更改为所需状态。例如,您可以自动化 Kubernetes 来为您的部署创建新容器,删除现有容器并将它们的所有资源用于新容器。 自动二进制打包 Kubernetes 允许您指定每个容器所需 CPU 和内存(RAM)。当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。 自我修复 Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。 密钥与配置管理 Kubernetes 允许您存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。 Kubernetes 组件 初学者首先要了解Kubernetes的基本概念,包括master、node、pod等。 Master Master是Kubernetes集群的大脑,运行着的守护进程服务包括kube-apiserver、kube-scheduler、kube-controller-manager、etcd和Pod网络等。 kube-apiserver 主节点上负责提供 Kubernetes API 服务的组件;它是 Kubernetes 控制面的前端。 kube-apiserver 在设计上考虑了水平扩缩的需要。 换言之,通过部署多个实例可以实现扩缩。 etcd etcd 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。 您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。 kube-scheduler 主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。 调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。 kube-controller-manager 在主节点上运行控制器的组件。 从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。 这些控制器包括: 节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应。 副本控制器(Replication Controller): 负责为系统中的每个副本控制器对象维护正确数量的 Pod。 端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)。 服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌. 云控制器管理器-(cloud-controller-manager) cloud-controller-manager 运行与基础云提供商交互的控制器 cloud-controller-manager 仅运行云提供商特定的控制器循环。您必须在 kube-controller-manager 中禁用这些控制器循环,您可以通过在启动 kube-controller-manager 时将 --cloud-provider 参数设置为 external 来禁用控制器循环。 cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中,核心的 Kubernetes 代码依赖于特定云提供商的代码来实现功能。在将来的版本中,云供应商专有的代码应由云供应商自己维护,并与运行 Kubernetes 的云控制器管理器相关联。 以下控制器具有云提供商依赖性: 节点控制器(Node Controller): 用于检查云提供商以确定节点是否在云中停止响应后被删除 路由控制器(Route Controller): 用于在底层云基础架构中设置路由 服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器 数据卷控制器(Volume Controller): 用于创建、附加和装载卷、并与云提供商进行交互以编排卷 Node 节点组件在每个节点上运行,维护运行 Pod 并提供 Kubernetes 运行环境。 kubelet 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。 kubelet 接收一组通过各类机制提供给它的 PodSpecs,确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。 kube-proxy kube-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。 kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。 如果有 kube-proxy 可用,它将使用操作系统数据包过滤层。否则,kube-proxy 会转发流量本身。 容器运行环境(Container Runtime) 容器运行环境是负责运行容器的软件。 Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。 Pod 在Kubernetes中,最小的管理元素不是一个个独立的容器,而是Pod。Pod是管理,创建,计划的最小单元. 一个Pod相当于一个共享context的配置组,在同一个context下,应用可能还会有独立的cgroup隔离机制,一个Pod是一个容器环境下的“逻辑主机”,它可能包含一个或者多个紧密相连的应用,这些应用可能是在同一个物理主机或虚拟机上。 Pod 的context可以理解成多个linux命名空间的联合 PID 命名空间(同一个Pod中应用可以看到其它进程) 网络 命名空间(同一个Pod的中的应用对相同的IP地址和端口有权限) IPC 命名空间(同一个Pod中的应用可以通过VPC或者POSIX进行通信) UTS 命名空间(同一个Pod中的应用共享一个主机名称) 同一个Pod中的应用可以共享磁盘,磁盘是Pod级的,应用可以通过文件系统调用。 由于docker的架构,一个Pod是由多个相关的并且共享磁盘的容器组成,Pid的命名空间共享还没有应用到Docker中 和相互独立的容器一样,Pod是一种相对短暂的存在,而不是持久存在的,正如我们在Pod的生命周期中提到的,Pod被安排到结点上,并且保持在这个节点上直到被终止(根据重启的设定)或者被删除,当一个节点死掉之后,上面的所有Pod均会被删除。特殊的Pod永远不会被转移到的其他的节点,作为替代,他们必须被replace. 三 通过kubeadm方式创建一个kubernetes 对kubernetes的概念和组件有所了解以后,就可以通过kubeadm的方式创建一个kubernetes集群。 安装前准备工作 创建虚拟机 创建至少2台虚拟机,可以在本地或者公有云。 下载部署软件 需要下载的软件包括calico、demo-images、docker-ce、kube、kube-images、kubectl、metrics-server 安装部署 具体安装过程参考官网文档: https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm/ 四 安装后的练习 安装后详读官方文档,做下面这些组件的练习操作,要达到非常熟练的程度。 Node Namespace Pod Deployment DaemonSet Service Job Static Pod ConfigMap Secrets Volume Init-containers Affinity and Anti-Affinity Monitor and logs Taints and Tolerations Cordon and Drain Backing up etcd 这些内容都非常熟练以后,基本就达到了入门的水平。

红亮 2020-03-02 11:09:17 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站