namespace

在Hadoop 2.0之前，也有若干技术试图解决单点故障的问题: Secondary NameNode。 它不是HA，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。 当NameNode失效的时候，Secondary NN并无法立刻提供服务，Secondary NN甚至无法保证数据完整性： 如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。 Backup NameNode 。 它在内存中复制了NN的当前状态，算是Warm Standby，可也就仅限于此，并没有failover等。 它同样是阶段性的做checkpoint，也无法保证数据完整性。 手动把name.dir指向NFS。安全的Cold Standby，可以保证元数据不丢失，但集群的恢复则完全靠手动。 单NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T。同时，所有的元数据信息的读取和操作都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。 HDFS

1. 当前HDFS架构和功能概述 我们先回顾一下HDFS功能。HDFS实际上具有两个功能： 命名空间管理 （Namespace management）和 块/存储管理服务 （block/storage management）。 1.1 命名空间管理 HDFS的命名空间包含目录、文件和块。命名空间管理：是指命名空间支持对HDFS中的目录、文件和块做类似文件系统的创建、修改、删除、列表文件和目录等基本操作。 1.2 块/存储管理 在块存储服务中包含两部分工作： 块管理 和 物理存储 。这是一个更通用的存储服务。其他的应用可以直接建立在Block Storage上，如HBase，Foreign Namespaces等。 1.2.1 块管理 A) 处理Data Node向Name Node注册的请求，处理datanode的成员关系，处理来自Data Node周期性的心跳。 B) 处理来自块的报告信息，维护块的位置信息。 C) 处理与块相关的操作：块的创建、删除、修改及获取块信息。 D) 管理副本放置（replica placement）和块的复制及多余块的删除。 1.2.2 物理存储 所谓物理存储就是：Data Node把块存储到本地文件系统中，对本地文件系统的读、写。 1.3 当前HDFS的架构 在当前的HDFS架构中（Hadoop v0.23之前），

其他人告诉我， using namespace std; 编写 using namespace std; 在代码中是错误的，我应该直接使用 std::cout 和 std::cin 代替。 为什么 using namespace std; 认为是不好的做法？ 是效率低下还是冒着声明模棱两可的变量（与 std 名称空间中的函数具有相同名称的变量）的风险？ 它会影响性能吗？ #1楼 请勿在全球范围内使用 仅在 全局使用 时才被视为“不良”。 因为： 您使正在编程的名称空间混乱。 当您使用 using namespace xyz 使用许多标识符时，读者将很难看到特定标识符的来源。 对于您的源代码的 其他 阅读者而言，正确的是对最常使用它的读者：您自己。 一两年后再来看看... 如果仅谈论 using namespace std 那么您可能不知道要获取的所有内容-当添加另一个 #include 或移动到新的C ++修订版时，可能会遇到您不认识的名称冲突。 您可以在本地使用 继续免费在本地（几乎）使用它。 当然，这可以防止您重复 std:: -重复也是不好的。 在本地使用它的习惯用法 在C ++ 03中，有一个习惯用法-样板代码-用于为您的类实现 swap 功能。 建议您实际上使用一个 using namespace std 的本地-或至少 using std::swap ： class

其他人告诉我， using namespace std; 编写 using namespace std; 在代码中是错误的，我应该直接使用 std::cout 和 std::cin 代替。 为什么 using namespace std; 认为是不好的做法？ 是效率低下还是冒着声明模棱两可的变量（与 std 名称空间中的函数具有相同名称的变量）的风险？ 它会影响性能吗？ #1楼 请勿在全球范围内使用 仅在 全局使用 时才被视为“不良”。 因为： 您使正在编程的名称空间混乱。 当您使用 using namespace xyz 使用许多标识符时，读者将很难看到特定标识符的来源。 对于您的源代码的 其他 阅读者而言，正确的是对最常使用它的读者：您自己。 一两年后再来看看... 如果仅谈论 using namespace std 那么您可能不知道要获取的所有内容-当添加另一个 #include 或移动到新的C ++修订版时，可能会遇到您不认识的名称冲突。 您可以在本地使用 继续免费在本地（几乎）使用它。 当然，这可以防止您重复 std:: -重复也是不好的。 在本地使用它的习惯用法 在C ++ 03中，有一个习惯用法-样板代码-用于为您的类实现 swap 功能。 建议您实际上使用一个 using namespace std 的本地-或至少 using std::swap ： class

像Mybatis、Hibernate这样的ORM框架，封装了JDBC的大部分操作，极大的简化了我们对数据库的操作。 在实际项目中，我们发现在一个事务中查询同样的语句两次的时候，第二次没有进行数据库查询，直接返回了结果，实际这种情况我们就可以称为缓存。 Mybatis的缓存级别 一级缓存 MyBatis的一级查询缓存（也叫作本地缓存）是基于org.apache.ibatis.cache.impl.PerpetualCache 类的 HashMap本地缓存，其作用域是SqlSession，myBatis 默认一级查询缓存是开启状态，且不能关闭。 在同一个SqlSession中两次执行相同的 sql查询语句，第一次执行完毕后，会将查询结果写入到缓存中，第二次会从缓存中直接获取数据，而不再到数据库中进行查询，这样就减少了数据库的访问，从而提高查询效率。 基于PerpetualCache 的 HashMap本地缓存，其存储作用域为 Session，PerpetualCache 对象是在SqlSession中的Executor的localcache属性当中存放，当 Session flush 或 close 之后，该Session中的所有 Cache 就将清空。 二级缓存 二级缓存与一级缓存其机制相同，默认也是采用 PerpetualCache，HashMap存储，不同在于其存储作用域为

最近cert manager进行升级，不再支持0.11以下的版本了，所以进行升级。但是发现不能直接通过更改镜像版本来升级，在Apps里的版本也是旧版本，部署后发现不支持，于是自已动手，根据文档整理了一套部署cert manager的过程。 ## Steps 1. create namespace `kubectl create namespace cert-manager` 2. install custome resource definition `kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.11/deploy/manifests/00-crds.yaml` 3. label cert-manager as disable-validation `kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true` 4. add jetstack helm repos `helm repo add jetstack https://charts.jetstack.io` 5. update local helm chart repository `helm repo

命名空间一个最明确的目的就是解决重名问题，PHP中不允许两个函数或者类出现相同的名字，否则会产生一个致命的错误。这种情况下只要避免命名重复就可以解决，最常见的一种做法是约定一个前缀。 例：项目中有两个模块：article和message board，它们各自有一个处理用户留言的类Comment。之后我可能想要增加对所有用户留言的一些信息统计功能，比如说我想得到所有留言的数量。这时候调用它们Comment提供的方法是很好的做法，但是同时引入各自的Comment类显然是不行的，代码会出错，在另一个地方重写任何一个Comment也会降低维护性。那这时只能重构类名，我约定了一个命名规则，在类名前面加上模块名，像这样：Article_Comment、MessageBoard_Comment 可以看到，名字变得很长，那意味着以后使用Comment的时候会写上更多的代码（至少字符多了）。并且，以后如果要对各个模块增加更多的一些整合功能，或者是互相调用，发生重名的时候就需要重构名字。当然在项目开始的时候就注意到这个问题，并规定命名规则就能很好的避免这个问题。另一个解决方法可以考虑使用命名空间。 注明： 本文提到的常量：PHP5.3开始const关键字可以用在类的外部。const和define都是用来声明常量的（它们的区别不详述），但是在命名空间里，define的作用是全局的

默认情况下，一个容器没有资源限制，几乎可以使用宿主主机的所有资源。 docker提供了控制内存、cpu、block io。但是实际上 主要是namespace和cgroup控制资源的隔离 。 Docker的隔离性 主要运用Namespace 技术 。传统上Linux中的PID是唯一且独立的，在正常情况下，用户不会看见重复的PID。然而在Docker采用了Namespace，从而令相同的PID可于不同的Namespace中独立存在。如，A Container 之中PID=1是A程序，而B Container之中的PID=1同样可以是A程序。虽然Docker可透过Namespace的方式分隔出看似是独立的空间，然而Linux内核（Kernel）却不能Namespace，所以即使有多个Container，所有的system call其实都是通过主机的内核处理，这便为Docker留下了不可否认的安全问题。 namespace（命名空间）可以隔离哪些 文件系统需要是被隔离的 网络也是需要被隔离的 进程间的通信也要被隔离 针对权限，用户和用户组也需要隔离 进程内的PID也需要与宿主机中的PID进行隔离 容器也要有自己的主机名 有了以上的隔离，我们认为一个容器可以与宿主机和其他容器是隔离开的。 恰巧Linux 的namespace可以做到这些。 使用Namespace进行容器的隔离有什么缺点呢？

1.docker介绍 1.1什么是docker Docker 是一个开源的应用容器引擎，基于 Go 语言 并遵从Apache2.0协议开源。 Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上。 1.2docker能解决什么问题 1.2.1高效有序利用资源 机器资源有限； 单台机器得部署多个应用； 应用之间互相隔离； 应用之间不能发生资源抢占，每个应用只能使用事先注册申请的资源。 1.2.2一次编译，到处运行 类似于java代码，应用及依赖的环境构建一次，可以到处运行。 1.2.docker底层原理介绍 1.2.1Linux的namespace和cgroup简单理解 namespace:类似于JAVA的命名空间 controll groups ： controll （system resource） （for） （process）groups 1.2.2Linux中的namespace 在Linux系统中，可以同时存在多用户多进程，那么对他们的运行协调管理，通过进程调度和进度管理可以解决，但是，整体资源是有限的，怎么把有限的资源（进程号、网络资源等等）合理分配给各个用户所在的进程？ image Linux Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的

一、为什么使用命名空间 考虑一种情况，当我们有两个同名的人，Zara，在同一个班里。当我们需要对它们进行区分我们必须使用一些额外的信息和它们的名字，比如这个区域，如果它们生活在不同的区域或者它们的母亲或父亲的名字，等等。 在您的C++应用程序中也会出现同样的情况。例如，您可能正在编写一些具有名为xyz（）函数的代码，并且还有另一个可用的库，它也具有相同的xyz（）函数。现在编译器无法知道您在代码中引用的xyz（）函数的哪个版本。 名称空间（namespace）被设计来克服这个困难，并被用作额外的信息来区分类似的函数、类、变量等等，它们在不同的库中具有相同的名称。使用名称空间，您可以定义定义名称的上下文。本质上，名称空间定义了一个范围。 二、命名空间的定义 在C语言中只有一个全局作用域： 1.C语言中所有的全局标识符共享一个作用域 2.标识符之间可能发生冲突 C++中提出了命名空间的概念： 1.命名空间将全局作用域分成不同的部分， 2.不同命名空间中的标识符可以同名而不会发生冲突 3.命名空间可以发生嵌套 4.全局作用域也叫默认命名空间 语法： namespace Name { namespace Internal { /*...*/ } /*...*/ } C++命名空间的使用： 使用整个命名空间：using namespace name; 使用命名空间中的变量：using