阿里dns是什么？

      阿里公共DNS地址阿里公共DNS面向全球普通用户，目前主要有两个DNS地址，分别为：223555223666阿里公共DNS三大亮点：1稳定(Stable)阿里公共DNS已经在拥有全球数百台服务器组成的集群，具备充足的带宽资源，自研高性能DNS系统和清洗中心，保障系统稳定和安全

云服务器的优势有哪些

为什么越来越多的企业和开发者使用云服务器来部署网站或应用总的来说，因为云服务器可提高效率，有助于节省企业和开发者的成本并获得更高收益。

1、敏捷性

云服务器，基于云端海量的虚拟资源池，支持资源的弹性伸缩，包括横向增加虚拟机的数量和纵向扩展资源的规模，可适应不断增长或波动的计算和带宽需求。当应用资源需求增加，你可以轻松扩展云端容量，同理，你也可以根据需求变化收缩资源规模。这种可根据运营策略的调整随需应变的敏捷性和高扩展性，是传统服务器无法比拟的，可使企业比竞争对手更具优势。

2、灾难恢复

使用云服务器，可为网站或应用数据提供更高的可靠性支持。无论业务规模大小，企业都应投资于灾难恢复工作，避免出现硬件故障导致的数据丢失、网站无法访问、服务器无法使用等突发情况。但要实现完善的容灾，通常需要高额的费用和专业技术知识，这对于小型企业来说无疑是很高的门槛。而云服务器，则可以有效地规避这些问题。我们以知了云OpenStack香港云服务器为例，知了云OpenStack云平台支持多重副本实时容灾、快照备份和回滚、热迁移等强大功能，如果某服务器集群出现硬件故障，系统将立即停止数据写入，而由其他备用服务器集群接管，并实现数据热迁移，在客户无感知的情况下快速恢复使用，且这些行为都是完全免费的。

3便捷性

云服务器优势还体现在业务的快速部署方面。传统服务器的使用，需要用户自己安装操作系统、配置防火墙、安装系列软件以搭建完善的应用部署环境。如今，这些工作都由云服务器供应商负责，供应商在云平台集成海量镜像，用户可一键获取并配置好相关应用程序的所需环境，即使技术实力较弱的小型企业也能轻松创建和管理线上IT服务。

4、成本控制

云计算削减了硬件的高成本。您花费高额费用无需购置硬件设备以及与之相关的监控、管理和维护成本。使用云服务器，您只需为需要的资源和服务付费，随时享受基于自选资源的模式，精准控制你的成本支出。并且，可以大幅节省运维管理费用。

5竞争力

您需要一个简单的方式来提高竞争力吗将业务迁移到云端，可以为每个开发者提供企业级技术支持。云服务器，可以使小型企业的业务部署和管理效率超出那些大型的成熟的竞争对手。例如知了云OpenStack香港云服务器，即开即用，秒级调度资源为您所用，业务可以最快上线，同时还能保持精简的资源组合以及管理上的敏捷性，这一切使您可以与更成熟的并肩前进，缩短与更强竞争对手之间的差距。

因此，云服务器优势有哪些总的来说，企业和开发者使用云服务器，在资源上可以做到随需随取，按需付费，在保持敏捷性的同时节省成本;在功能上支持多重数据备份和热迁移，使数据可靠性远超传统IT托管模式;在管理上可简化运维，使应用程序的部署和管理更有效率。使用云服务器，或者私有云，已经成为目前众多企业IT架构转型的重要方式。相信随着时间的推移将为越来越多的企业和开发者创造更高价值。

现在很多软件都标了IPV6，表示软件已经支持IPV6网络协议，并且已经配置好了IPV6访问的服务器集群。用户端路由器能够正常接入获取网络运营商的IPV6，就可以使用IPV6进行数据通信，如果设备不支持IPV6就使用IPV4。软件已经支持IPV6，好还是不好呢？答案是，很好。

大家知道IPV4公网IP地址已经分配完成，意味着根服务器再也没有IPV4地址分配给网络运营商。IPv4使用32位（4字节）地址，因此地址空间中只有4,294,967,296（2的32次方）个地址。

不过，一些地址是为特殊用途所保留的，如专用网络（约1800万个地址）和多播地址（约27亿个地址）。而IPV6地址总长度128位，IPv6的地址空间扩大到2的128次方。

这个空间大到无法想象，也就是说，地球上每一平方米，都可以有10的26次方的地址，甚至可以分配地址到空中的尘埃。IPV6的优势：IPV6提供了端到端的安全性。它允许设备在网络之间漫游，而且不会中断连接。IPV6分组报头包含的字段减少了一般，并且所有的字段都与64位边界对齐，相比IPV4，极大的提高了处理速度，查找速度要快得多。

原来包含在IPV4报头中的很多信息都删除了，但可在基本报头字段后面添加可选的扩展报头，将这些信息或其中一部分加入报头。IPV4大量的使用广播，这样导致了很多问题，最糟糕的是广播风暴，不受控制的到处转发广播可能耗尽所有带宽，导致整个网络瘫痪。广播令人讨厌的另一个点事，会导致网络中的每台设备都中断。

广播发送后，每台设备都必须停下手中的工作，对广播做出响应，不管广播是否发送给它。IPV6是没有广播的概念的，它使用组播。IPV6还支持另外2种通信：单播和任意播。任意播可以将同一个地址分配给多台设备，而向该地址发送数据流时，它会被路由器共享该地址的最近主机。现在这么多软件可以使用IPV6后面的战略意义：

IPV4时代，我们国家是没有根服务器的。根服务器主要用来管理互联网的主目录，全世界IPV4根服务器只有13台，1个为主根服务器在美国。其余12个均为辅根服务器，其中9个在美国，2个在欧洲（位于英国和瑞典），亚洲1个位于日本。这就意味着，美国可以通过控制根服务器而控制整个互联网，对于其他国家的网络安全构成了潜在的巨大威胁。

IPV6时代，我国部署了4台根服务器（1台主根服务器、3台辅根服务器），打破了我国没有根服务器的困境，形成了13台原有根加上25台IPV6根的新格局。这也是为什么我们大跨步推进IPV6的原因，网络的自主性、安全性可以掌握在我们自己手里。我国首个IPV6公共DNS正式发布首选

DNS 240C::6666备用 DNS

240C::6644如何查看自己的网络是否已经使用IPV6？浏览器访问域名：wwwtest-ipv6com

IPV6连接测试通过，则表示路由器能够获取到IPV6地址。不通过，查看一下自己的路由器是否支持IPV6，路由器支持IPV6，联系宽带运营商开通IPV6即可。这么多APP可以使用IPV6表示，我国的IPV6在大跨步的发展。三大基础电信企业的超大型、大型数据和中小型IDC已经全部完成IPV6改造。各大网站已经均支持IPV6的访问。我国IPV6活跃用户数已经达13亿。

我买了但是后悔死了，同样的邮件内容会被阿里巴巴的邮件系统判定为垃圾邮件，完全发不出去了，用其他QQ邮箱，163邮箱（免费）都能发出去，换个内容又能发出去了，真是垃圾的要死。

综合看来阿里巴巴只适合大企业之间的沟通，并不适合小企业做推广

在完成事件接入的需求时，我们需要记录上一个批次拉取的事件，并与当前拉取到的事件做出比对，从而进行差分。我们目前的做法是使用redis来进行缓存:将上一个批次拉取到的事件缓存到一个list中。但是当事件数量过多时，value的大小会超过1M的限制，直接抛出异常。这其实是Tair出于性能的考虑而做出的限制，本文将谈谈我个人对于bigKey的理解。

顾名思义，bigKey指一个key对应的value占据的内存空间相对比较大，bigKey通常会有两种表现形式:

bigKey一旦产生，将会对tair的性能以及稳定性造成较大的影响，下面我将详细介绍一下bigKey的危害。

bigKey给tair带来的危害是多方面的，性能下降只是其中的一方面，极端情况下，bigKey甚至会导致缓存服务崩溃。下面我将从几个角度进行分析。

我们可以看到:

另外，在Redis执行异步重写操作时(bgrewriteaof)，主线程会fork出一个子进程来执行重写命令，这个子进程会与主线程共享内存。当主线程收到了新增或者修改一个key的命令，主线程会申请一块额外的内存空间来保存数据。但如果这个key是一个bigKey时，主线程会去申请一块更大空间，同样会阻塞主线程(与JVM分配内存一样，涉及锁和同步)。如果申请不到足够的空间，会导致Swap甚至会有OOM的风险，这同样会降低Redis的性能和稳定性。

Tair中一个key最大为1M，我们就以1M举例，当访问这个key的QPS为1000时，每秒将会有1GB左右的流量，对于带宽来说将是一个较大压力。如果这个bigKey是一个热点key时，后果将不堪设想。

如果主从同步的 client-output-buffer-limit 设置过小，并且 master 存在大量bigKey(数据量很大)，主从全量同步时可能会导致 buffer 溢出，溢出后主从全量同步就会失败。如果主从集群配置了哨兵，那么哨兵会让 slave 继续向 master 发起全量同步请求，然后 buffer 又溢出同步失败，如此反复，会形成复制风暴，这会浪费 master 大量的 CPU、内存、带宽资源，也会让 master 产生阻塞的风险。 另外，当我们使用Redis Cluster时，由于Redis Cluster采用了同步迁移的方式，bigKey同样会阻塞主线程。这里提一下Codis，Codis在迁移bigKey时，使用了异步迁移 + 指令拆分的方式，对于bigKey (集合类型) 中每个元素，用一条指令进行迁移，而不是把整个 bigKey 进行序列化后再整体传输。这种化整为零的方式，就避免了 bigKey 迁移时，因为要序列化大量数据而阻塞的问题。

当我们写入或者读取大量bigKey的时候，很有可能导致输入/输出缓冲区溢出。如果客户端占用的内存总量超过了服务器设置的maxmemory时(默认4GB)，将会直接触发服务器的内存淘汰策略，如果有数据被淘汰，再要获取这些数据就需要到后端回源，间接降低了缓存系统的性能。同时，淘汰的如果是bigKey也同样会阻塞主线程。另外，在极端情况下，多个客户端占用了过多的内存将导致OOM，进而使得整个redis进程崩溃。

使用切片集群的时候，我们通常会将不同的key存放在不同的实例上，如果存在bigKey的话，会导致相应实例的数据量增大，内存压力也相应增大。

常用的做法是通过/redis-cli --bigkeys命令对整个redis中的键值对进行统计，输出每种数据类型中最大的 bigkey 的信息。一般会配合-i参数一起使用,控制扫描间隔，避免长时间扫描降低 Redis 实例的性能。另外该命令不要在业务高峰期使用。

或者我们可以通过debug object key 命令去查看serializedlength属性，serializedlength表示key对应的value序列化后的字节数，通过观察serializedlength的大小可以辅助排查bigKey。使用scan + debug object key命令，我们可以计算其中每个key的serializedlength，进而发现其中的bigKey，并做好相应的监控和处理。不过对于集合类型的bigKey，debug object key 命令的执行效率不高，存在阻塞redis的风险。

另外，在读取bigKey的时候，我们尽量不要一次性将全部数据读取出来，而是采用分批的方式进行读取:利用scan命令进行渐进式遍历，将大量数据分批多次读取出来，减小redis的压力，避免阻塞的风险。

同样的，在删除bigKey的时候我们也可以使用scan命令来进行批量删除。如果你是用的redis是40之后的版本，则可以利用unlink命令配合lazy free配置(需要手动开启)来进行异步删除，避免主线程阻塞。