閱讀本文約花費: 1 (分鐘)收录查询 Alexa排名查询 PR查询 Sogou Rank查询 域名注册查询 中文域名转码 国家或地区域名 CN域名到期时间列表 今天CN域名删除列表 明天CN域名删除列表 后天CN域名删除列表 国际域名到期时间列表 今天国际域名删除列表 明天国际域名删除列表 后天国际域名删除列表 WHOIS查询 IP地址查询 IP WHOIS查询 HTTP状态查询 Unicode编码转换 HTML/JS互转 JS和HTML格式化 JS/VBS加密/解密 Escape加密/解密 MD5加密 汉字转换拼音 CSS在线编辑器 查看网页源代码 HTML颜色代码 No tags for this post.
閱讀本文約花費: 8 (分鐘)文/六神磊磊懒得管段落了，就这么一句一句写。苟晶，陈春秀，还有王娜娜、罗彩霞……这些，都是高考被人冒名顶替的女孩。看了她们全部人的采访，你有没有发现一点：她们都很像？我说的“像”，不只是说她们都来自农村、家庭贫困。也不只是说都是女孩。还包括她们都给人同一种感觉——很老实、很良善。我当记者，也算采访过各类人。提意见的、闹事的，等等，什么人什么性格，基本上几眼能看透。这些被顶替的女孩子，她们个个毫无“狼性”，反而“羊性”很足。不会搞事，不会发狠。你看她们的采访，虽然也都坚持要讨个说法，但是说到那些伤害她们的人的时候，没有什么特强的憎恨、复仇的情绪，没有什么老子要搞出个天大的事那种感觉，没有牙尖嘴利，没有口吐芬芳，没有打滚痛骂，甚至让我们都觉得：骂得不够痛快！你看陈春秀说起那个顶替她的人——陈双双。称别人还是用的“人家”。还说她“很漂亮”，说看照片就感觉自己“好像跟人家不是一个档次的”。还多次自己哽咽起来。 这要换了我，一定早已经问候对方十八代外加先人板板了。可陈春秀还反复哽咽，还说人家漂亮。苟晶说起那个下黑手顶替自己的老师，居然不断地说，心疼他“头发都白了”。还反复说这老师“教语文还不错”。并且苟晶还一再地讲：“我针对的不是老师你个人。”“这么多年，我也没有想过去针对你。”好像还怕话重一点，就会伤了那个老师的心一样。 我都迷惑了：到底谁是受害者？你还用得着…
閱讀本文約花費: 7 (分鐘)专门为云原生软件构建可持续生态系统的云原生计算基金会（简称CNCF）于本月23日（当地时间）正式宣布，Harbor已经成为第11个正式毕业的项目。从孵化阶段、发展成熟一路走向正式毕业，Harbor项目不仅获得更高的采用率、更加开放的治理流程与成熟的功能，同时也在社区发展、可持续性及项目包容性方面做出坚定的承诺。Harbor是一种开源代码注册表，可通过策略与基于角色的访问控制实现工件保护，扫描镜像内容使其免受漏洞侵害，最后对镜像进行可信签名。作为云原生计算基金会下辖的孵化项目，Harbor成为保障合规性、性能与互操作性的好帮手，可帮助用户跨Kubernetes与Docker等云原生计算平台，持续安全地管理各类工件。目前，Harbor已经被引入众多知名企业的生产体系当中，包括CaiCloud、中国移动、Hyland Software、京东、Mulesoft、三星SDS、Trend Micro以及VMware等等。就在上个月，Harbor 2.0版本全面推出。此版本增加了对开放容器计划（OCI）工件的支持，允许用户在其中存储大量云原生工件，例如容器镜像、Helm图表、OPA以及Singularity等。开发人员可以使用OCI索引中的OCI工件或打包工件，轻松享受Harbor项目带来的策略选项、复制功能以及基于角色的访问控制等成果。云原生计算基金会CTO/CO…
閱讀本文約花費: 17 (分鐘)幸存者偏差(Survivorship Bias) 目录[隐藏]1 什么是幸存者偏差2 幸存者偏差的案例[1]3 参考文献 [编辑] 什么是幸存者偏差 幸存者偏差，另译为“生存者偏差”或“存活者偏差”，是一种常见的逻辑谬误（“谬误”而不是“偏差”），意思是只能看到经过某种筛选而产生的结果，而没有意识到筛选的过程，因此忽略了被筛选掉的关键信息。这东西的别名有很多，比如“沉默的数据”、“死人不会说话”等等。[编辑] 幸存者偏差的案例[1] 关于幸存者偏差(Survivorship Bias),有一个较知名的“飞机防护”案例。 1941年,第二次世界大战中,美国哥伦比亚大学统计学沃德教授(Abraham Wald)应军方要求,利用其在统计方面的专业知识来提供关于《飞机应该如何加强防护,才能降低被炮火击落的几率》的相关建议。沃德教授针对联军的轰炸机遭受攻击后的数据,进行研究后发现:机翼是最容易被击中的位置,机尾则是最少被击中的位置。沃德教授的结论是“我们应该强化机尾的防护”,而军方指挥官认为“应该加强机翼的防护,因为这是最容易被击中的位置”。沃德教授坚持认为:(1)统计的样本,只涵盖平安返回的轰炸机;(2)被多次击中机翼的轰炸机,似乎还是能够安全返航;(3)而在机尾的位置,很少发现弹孔的原因并非真的不会中弹,而是一旦中…
閱讀本文約花費: 23 (分鐘)当MySQL单表记录数过大时，增删改查性能都会急剧下降，可以参考以下步骤来优化： 单表优化 除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度，一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量： 字段 尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED VARCHAR的长度只分配真正需要的空间 使用枚举或整数代替字符串类型 尽量使用TIMESTAMP而非DATETIME， 单表不要有太多字段，建议在20以内 避免使用NULL字段，很难查询优化且占用额外索引空间 用整型来存IP 索引 索引并不是越多越好，要根据查询有针对性的创建，考虑在WHERE和ORDER BY命令上涉及的列建立索引，可根据EXPLAIN来查看是否用了索引还是全表扫描 应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃使用索引而进行全表扫描 值分布很稀少的字段不适合建索引，例如”性别”这种只有两三个值的字段 字符字段只建前缀索引 字符字段最好不要做主键 不用外键，由程序保证约束 尽量不用UNIQUE，由程序保证约…
閱讀本文約花費:
閱讀本文約花費: 5 (分鐘)by 韩寒 (2012-04-01 08:38:41) 冬天花败，春暖花开，有人离去，有人归来。 @韩寒，http://weibo.com/hanhan。第一篇长微博，献给我的偶像。 2003年4月1日，我在开车从北京回上海的途中。在那之前，我并不是你的歌迷，我只知道你唱过《倩女幽魂》，我甚至觉得，你好久没做宣传，没出作品，已经过气了。 对你的了解从京沪高速的山东段开始。那里的山上都是顽石，少见绿色。以往开车路过河北，山东和江苏，打开电台，要不是卖春药的，就是治性病的，还不停的有托打电话和主持人互动，说疗效好，去哪才能再买到。我常想，这么明显的忽悠，怎么可能有人相信。这个世界上真的充斥着荒诞。但那一次开车的旅程，我能调到所有的频率里都只有你的生平介绍，当然还有你唱过的歌。我甚至发现，有时候，我偶然会哼唱两句的不知名旋律，原来都是你的。路过临沂，电台主持人甚至自己开唱《奔向未来日子》。 对你来说，已经没有未来的日子了。你奔向了永远不会来的日子。那些岁月里，我是一个轻狂气傲的无知少年，对所谓港台巨星嗤之以鼻，这也让我错过了你。那几年我在北京，迷茫的就像在能见度只有一米起了大雾的国…
閱讀本文約花費: 7 (分鐘)面试题 如何设计可以动态扩容缩容的分库分表方案？ 面试官心理分析 对于分库分表来说，主要是面对以下问题： 选择一个数据库中间件，调研、学习、测试； 设计你的分库分表的一个方案，你要分成多少个库，每个库分成多少个表，比如 3 个库，每个库 4 个表； 基于选择好的数据库中间件，以及在测试环境建立好的分库分表的环境，然后测试一下能否正常进行分库分表的读写； 完成单库单表到分库分表的迁移，双写方案； 线上系统开始基于分库分表对外提供服务； 扩容了，扩容成 6 个库，每个库需要 12 个表，你怎么来增加更多库和表呢？ 这个是你必须面对的一个事儿，就是你已经弄好分库分表方案了，然后一堆库和表都建好了，基于分库分表中间件的代码开发啥的都好了，测试都 ok 了，数据能均匀分布到各个库和各个表里去，而且接着你还通过双写的方案咔嚓一下上了系统，已经直接基于分库分表方案在搞了。 那么现在问题来了，你现在这些库和表又支撑不住了，要继续扩容咋办？这个可能就是说你的每个库的容量又快满了，或者是你的表数据量又太大了，也可能是你每个库的写并发太高了，你得继续扩容。 这都是玩儿分库分表线上必须经历的事儿。 面试题剖析 停机扩容（不推荐） 这个方案就跟停机迁移一样，步骤几乎一致，唯一的一点就是那个导数的工具，是把现有库表的数据抽出来慢慢倒入到新的库和表里去。但是最好别这么玩儿，有点不太…
閱讀本文約花費: 6 (分鐘)by 韩寒 (2012-07-03 09:49:38) 四年前，汶川地震，我去四川。隐约记得地震几天后，政府为了防止瘟疫的发生和蔓延，决定捕杀在街上没有主人的狗。作为一个特别喜爱狗的人，虽然觉得难过，但也在非常时期对政府这个决议表示了理解。告别四川，我捡回来一条没有主人的狗，经过检疫，将他带回了上海。之所以在今天提起此事，是因为这条狗来自什邡市的红白镇。 今夜，什邡这两个字被再次提起。回想起四年前在什邡的一路上，两边都是被摧毁的巨型工厂，军队在平地驻扎，这些场景，似幻似虚。 我想到了自己的家乡，上海化工重区金山区亭林镇的一个农村。我目睹着故乡是如何从一个绿水炊烟，空气新鲜的地方变成今天这样，十年，只用了十年，老家已经变成河水如染料，空气似毒药的地方。当年发展这些污染严重的工业项目时，政府骗村民说要发展GDP，政府只有税收多了，才能造福大家。十年过去，周围村民们的生活压力和福利状况比起以前没有任何的改善，但我们再呼吸不到好空气了，我老家边的那条河更是惨不忍睹，一周七色，看一眼就知道是礼拜几。亭林镇的老百姓选择了忍，因为环境部门的检测报告显示，一切合格。是，做人做事，如果没有了下限，可不什么都合格么。可你见过连小龙虾都活不下去的水质么？ …
閱讀本文約花費: 3 (分鐘)自己经常访问的10个国外技术社区分享出来。想要玩转这些资源的前提，要么自身外语水平不错，要么找个好的翻译工具，不然….。 不过，也不要一味的崇拜国外的技术，其实你看一圈下来国外社区不错的也就那几个，而国内的技术社区像掘金、思否也都是比较优秀的。当你在羡慕外边的景色时，殊不知别人也在羡慕着你。 授人以渔 1、dev dev社区和国内的掘金社区很相似，技术分类也比较多，像Java、Python、js、分布式等应有尽有，文章质量普遍都还不错，其实如果平时多留意不难发现，掘金上有一些文章是翻译自dev社区。 不过，在这还是要吹一波彩虹屁，无论界面布局还是文章质量，更喜欢掘金一点，难得的高质量技术社区。 地址：https://dev.to/ 2、stackoverflow stackoverflow 一个问答类的技术社区，和国内知乎比较相似，但与知乎不同的是stackoverflow 更垂直于技术，不像知乎内容比较杂。 地址：https://stackoverflow.com/questions 3、simpleprogrammer simpleprogrammer ：简单的程序员，这个网站上纯技术文章不多，指导建议性的文章比较多。讲述一些职场、以及软件开发中的一些“ 潜规则”。 地址：https://simpleprogrammer.com/ 4、…
閱讀本文約花費: 18 (分鐘) 编辑推荐:文章主要介绍了微服务架构特性，微服务网关的分类以及作用，SIA-GateWay等，希望能对您有所帮助。 一. 背景 软件架构，总是在不断的演进中… 把时间退回到二十年之前，当时企业级领域研发主要推崇的还是 C/S 模式，PB、Delphi 这样的开发软件是企业应用开发的主流。随着时间不断的推移，基于浏览器的的 B/S 架构开始渐渐流行了起来。初期，Web 开发 ASP 还占据了不少优势，但 JSP 的预编译模式让性能有了很大的提升，随后基于 JAVA 语言的 J2EE 架构变的越来越流行。 早期软件架构基本都是单体架构，系统之间往往不需要进行交互，这也导致数据孤岛和 ETL 工具的发展。随着企业应用越来多，相互的关系也越来密切。应用之间也迫切需要进行实时交互访问，随后基于 XML 的异构系统集成和数据交互技术开始被很多公司采用，SOA 的概念被提了出来，web service 逐渐流行起来。 互联网时代，很多公司为了适应更加灵活的业务需求，基于 HTTP 协议和 Restful 的架构风格及简洁和结构清晰的 JSON 语言成为企业开发的最佳实践，在 SOA 架构中，企业服务总线技术 ESB 所暴露的集中式架构的劣势让开发者明白基于注册和发现的分布式架构才是解决问题的关键办法。由此，微服务架构逐渐流行起来。 在《微服务设计》中如…
閱讀本文約花費: 10 (分鐘)在JDK8之前，处理日期时间，我们主要使用3个类，Date、SimpleDateFormat和Calendar。 这3个类在使用时都或多或少的存在一些问题，比如SimpleDateFormat不是线程安全的， 比如Date和Calendar获取到的月份是0到11，而不是现实生活中的1到12，关于这一点，《阿里巴巴Java开发手册》中也有提及，因为很容易犯错： 不过，JDK8推出了全新的日期时间处理类解决了这些问题，比如Instant、LocalDate、LocalTime、LocalDateTime、DateTimeFormatter，在《阿里巴巴Java开发手册》中也推荐使用Instant、 LocalDateTime、DateTimeFormatter： 但我发现好多项目中其实并没有使用这些类，使用的还是之前的Date、SimpleDateFormat和Calendar，所以本篇博客就讲解下JDK8新推出的日期时间类，主要是下面几个： Instant LocalDate LocalTime LocalDateTime DateTimeFormatter 1. Instant 1.1 获取当前时间 既然Instant可以代替Date类，那它肯定可以获取当前时间： 输出结果： 2020-06-10T08:22:13.759Z 细心的你会发现，这个时间…
閱讀本文約花費: 51 (分鐘)环境搭建概述 1.K8S是什么？ K8S全称是Kubernetes，是一个全新的基于容器技术的分布式架构领先方案，基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。 如果我们的系统设计遵循了kubernetes的设计思想，那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块，都可以使用K8S来管理，我们不必再费心于负载均衡的选型和部署实施问题，不必再考虑引入或自己开发一个复杂的服务治理框架，不必再头疼与服务监控和故障处理模块的开发。总之，使用kubernetes提供的解决方案，会大大减少开发成本，同时可以将精力更加集中于业务本身，而且由于kubernetes提供了强大的自动化机制，所以系统后期的运维难度和运维成本大幅降低。 2.为什么要用K8S? Docker 这个新兴的容器化技术当前已经被很多公司所采用，其从单机走向集群已成必然，而云计算的蓬勃发展正在加速这一进程。Kubernetes 作为当前唯一被业界广泛认可和看好的 Docker 分布式系统解决方案。可以预见，在未来几年内，会有大量的新系统选择它，不管是运行在企业本地服务器上还是被托管到公有云上。 3.使用K8S有哪些好处？ 使用Kubernetes就是在全面部署微服务架构。微服务架构的核心就是将一个巨大的单体应用分解为很多小的互相连接的微服务，一个微服…
閱讀本文約花費: 8 (分鐘)解Bug之路-记一次存储故障的排查过程 高可用真是一丝细节都不得马虎。平时跑的好好的系统，在相应硬件出现故障时就会引发出潜在的Bug。偏偏这些故障在应用层的表现稀奇古怪，很难让人联想到是硬件出了问题，特别是偶发性出现的问题更难排查。今天，笔者就给大家带来一个存储偶发性故障的排查过程。 Bug现场 我们的积分应用由于量非常大，所以需要进行分库分表，所以接入了我们的中间件。一直稳定运行，但应用最近确经常偶发连接建立不上的报错。报错如下: 而笔者中间件这边收到的确是: 这样的告警。整个Bug现场如下图所示: 偶发性错误 之前出过类似register err这样的零星报警，最后原因是安全扫描，并没有对业务造成任何影响。而这一次，类似的报错造成了业务的大量连接超时。由于封网，线上中间件和应用已经稳定在线上跑了一个多月，代码层面没有任何改动！突然出现的这个错误感觉是环境出现了某些问题。而且由于线上的应用和中间件都是集群，出问题时候都不是孤立的机器报错，没道理所有机器都正好有问题。如下图所示: 开始排查是否网络问题 遇到这种连接超时，笔者最自然的想法当然是网络出了问题。于是找网工进行排查，在监控里面发现网络一直很稳定。而且如果是网络出现问题，同一网段的应用应该也都会报错才对。事实上只有对应的应用和中间件才报错，其它的应用依旧稳稳当当。 又发生了两次 就在笔者觉得这个…
閱讀本文約花費: 12 (分鐘) 本文从问题出发，从系统高可用性和高性能出发，系统的总结了微服务网关架构的技术要点，并且对相关技术点的原理和应用做了概要描述，希望对大家的学习有所帮助。 随着应用与技术越来越复杂，无论研发过程或者是运维过程都面临更多困难，为了应对上述困难，马丁提出了微服务概念，这几年微服务应用逐渐流行开来。微服务应用建设，应当是先建设微服务基础设施，然后在这个基础上拆分应用，可见微服务基础设施建设是实施微服务的核心，而微服务网关就是其中最重要的微服务基础设施之一。 传统网络层的网关主要作用是链接和协议转换，而微服务网关处于应用层，其主要功能是路由转发，当然在微服务环境中，网关作为外部请求和内部系统的桥梁（外部网关）或者内部系统之间转发的桥梁（内部网关），一定会面临很多新的挑战。比如： 请求流量挑战，流量随着时间推移不断增长，或者流量的峰值超出系统处理极 系统稳定性，由于网关关联了多个系统，无论哪个系统出现延迟或者异常都可能导致网关不稳定 微服务网关职责划分，正确的职责划分可以优化整个微服务体系，使得整个系统最优雅 微服务网关分析 从外部环境看微服务网关面对上述挑战，因此需要深入分析。首先面对流量的挑战，导致流量变化可能是正常请求也可能是异常请求，这时需要系统自动感知到，如果是异常流量而且接近峰值时，能自动降级或者限制该类请求，如果是正常请求则应该自动扩容，当流量下降…
閱讀本文約花費: 11 (分鐘)在高并发、异步化等场景，线程池的运用可以说无处不在。线程池从本质上来讲，即通过空间换取时间，因为线程的创建和销毁都是要消耗资源和时间的，对于大量使用线程的场景，使用池化管理可以延迟线程的销毁，大大提高单个线程的复用能力，进一步提升整体性能。 今天遇到了一个比较典型的线上问题，刚好和线程池有关，另外涉及到死锁、jstack命令的使用、JDK不同线程池的适合场景等知识点，同时整个调查思路可以借鉴，特此记录和分享一下。 01 业务背景描述 该线上问题发生在广告系统的核心扣费服务，首先简单交代下大致的业务流程，方便理解问题。 绿框部分即扣费服务在广告召回扣费流程中所处的位置，简单理解：当用户点击一个广告后，会从C端发起一次实时扣费请求(CPC，按点击扣费模式)，扣费服务则承接了该动作的核心业务逻辑：包括执行反作弊策略、创建扣费记录、click日志埋点等。 02 问题现象和业务影响 12月2号晚上11点左右，我们收到了一个线上告警通知：扣费服务的线程池任务队列大小远远超出了设定阈值，而且队列大小随着时间推移还在持续变大。详细告警内容如下： 相应的，我们的广告指标：点击数、收入等也出现了非常明显的下滑，几乎同时发出了业务告警通知。其中，点击数指标对应的曲线表现如下： 该线上故障发生在流量高峰期，持续了将近30分钟后才恢复正常。 03 问题调查和事故解决过程 下面…