问题场景 服务器出现大量 TCP 连接状态为 CLOSE_WAIT，将系统资源耗尽，导致业务处理失败。 ## 处理方式 重启导致问题的进程，释放 TCP 连接后服务恢复正常。 调整服务器网络参数： * net.ipv4.tcp_keepalive_time=600，tcp 连接空闲 10 分钟后发送探测包，默认是 7200 秒（两小时） * net.ipv4.tcp_keepalive_intvl=15，每次探测包间隔 15 秒，默认是 75 秒 * net.ipv4.tcp_keepalive_probes=5，一共发送 5 次探测包，默认是 9 次 让内核尽快检测出空闲连接并释放。 ## 分析 服务器环境是 Java、Tomcat。服务端在收到客户端 FIN 包后进入 CLOSE_WAIT，但服务端没有发送 FIN 包，具体原因没有查明。猜测的原因是 * 服务端的业务处理阻塞，导致发送不了 FIN 包 * 网络问题导致依赖的基础库 bug 附：TCP 连接状态图 ![8b538e707e964084a2161844efb023ea-tcp.jp.... CLOSE_WAIT 问题分析 Linux
背景 很多人都有收藏网络资料的习惯，常用的方式有两种： 1. 浏览器书签 2. 笔记软件 对于个人的知识管理这两种方式都比较有效，但是如果要将自己整理好的内容分享给其他人时，可选的方式就比较有限了，特别是当要批量分享某个类目时。 除了分享的场景，很多时候还 需要大众的力量进行资源的完善和维护 。完善意味着挖掘新的资源添加进来，维护意味着修正一些不可用的资源。这个场景下最有效的方式是通过 Wiki 进行协作编辑。 Wiki 方式主要站点是 [WiKiPedia] ，但因为维基百科是一个综合化的知识库，并且对于主题侧重的是权威性，所以一些我们觉得有帮助但比较小众的资源链接是整合不到其中的。 目前流行的一种方式是通过 [GitHub] 进行知识资源整理，比如一些关注数非常高的资源导航库（Awesome/资源合集等）。通常的协作流程是通过 Pull Request 发起，库 Owner 同意合并后就能够将 PR 发起者的变更（比如加入一个有价值的链接）同步到主库。这个协作方式略比 Wiki 复杂一些，但在程序员圈子是非常受欢迎的。 ### 现状分析 通过观察 GitHu.... 链接熔炉设计 开源项目
背景 这里的数据库复制指的是将 主 业务数据库实例上的库通过同步机制（比如 MySQL binlog）准实时（比如最大延迟为 3s）复制到其他数据库实例上，这些实例库只做查询，不做数据写入。 这套架构设计的主要优势： * 各业务应用能够方便地在自己的 DB 实例上进行业务查询，比如通过 join 主业务库 * 在不明确业务边界、没有梳理好业务对应技术模块时可以最小成本进行变更或扩展 * 实现读写分离，提升性能 ### 一些问题 实际在实施过程中主要遇到两个问题： 1. 不可能实时完成数据同步，将造成业务上面的不一致，比如调用主库服务更新数据后，在业务库上不能实时查询到已更新的数据 2. 很难保证高可用（在使用阿里 DTS 时出现过多次问题，自己做主从可能会好一些） 为了满足业务发展，复制库的数量会逐步增多（比如新开一个产品可能就需要多复制一套库），以上两个问题可能会导致严重的故障， [CAP] 不能兼得。 ### 服务化 基于数据库复制架构的核心理念是将数据源暴露给应用，开发者直接针对数据源进行开发，是一种非常直接的方式。 但随着业务的逐渐清晰，一些业务逻辑是可以抽.... 基于数据库复制的技术架构讨论 数据库
背景 大多数应用或多或少都会涉及到敏感数据处理，比如用户的手机号、身份证号，甚至银行卡账号。作为应用的开发者，如何 安全地 维护这些敏感数据呢？ 这里讨论的安全不是指服务器如何保护，而是在数据库层面做敏感数据的分离： * 业务库中不保存敏感数据，只保存混淆过的数据，比如电话字段保存的是 133****9961，在数据层面就进行脱敏 * 敏感数据统一保存在另一个库中，有应用调用一个服务来建立原值和混淆值的映射关系 * 业务库中因为保存的是脱敏过的数据，通过只读复制镜像可以很方便地提供给其他服务使用，比如 OLAP * 除了技术开发上方便，运维上也方便了很多，降低了敏感数据被暴露到外部的可能性 ### 技术设计 提供服务接口给应用存取敏感数据，本质上是一个 KV 存取服务。 一些细节： * 表 protyle 的 domain 字段用于标识该记录的作用域，在一个作用域上相同的值要保证唯一 * 表 protyle 的 ha.... 敏感数据处理 架构设计
背景 社区是以 UGC（用户生产内容）模式下运作的，一个社区的核心资产就是用户产生的内容。高质量的内容可让社区更容易获得流量，然后通过流量变现方式进行盈利（比如广告）。 在这个生态系统中，存在几种角色： * 创作者：内容的生产者，比如帖子作者、回帖者 * 浏览者：内容的消费者，和创作者角色经常相互切换 * 社区：聚集创作者和浏览者，聚合内容，沉淀出有价值的知识 ### 价值体现 社区的核心价值在于能给创作者、浏览者带来快乐。为了达到这个目标，我想至少需要从以下几点进行努力： * 确定的受众：程序员、设计师中的高水平群体 * 极致的体验：实用、简约的界面，方便操作，稳定、高性能、安全 * 好玩的特性：比如实时交互，金融系统，思绪，小黑屋等 * 真实的成就：通过一系列数据（比如粉丝数、发帖/回帖数、浏览量、积分、创建标签数等）量化用户在社区的个人能力 * 积累与成长：用户可从高质量的内容中进行学习，同其他高水准的用户交互而获得成长，这需要我们不断积累、整理内容，并实现更科学的内容筛选机制 上面是一些这段时间对社区运营的总结，算是过往思考的一些沉淀。 ### 生态系统 前面介绍过 U.... UGC 社区价值生态 黑客派
###场景 我们的登录表单一般都是 input text + input password： 登录 登录后如果用户选择了保存登录密码，那后续界面中如果有形如： 这样的两个 input（text+password）接在一起，那浏览器就会自动填充登录时的输入。 要用程序清空自动填充有两个方案： ###使用 autocomplete 属性 在不需要自动填充的 input 上设置 autocomplete 属性： 这个方案对于某些版本的浏览器可能不行。 ###使用假的 input 让浏览器去填充 在页面 `` 后加入： 这个方案原理是让浏览器去填充用户实际上看不到的 input。虽然看上去代码比较 low，但是很实用。 参考：Disabling Chrome Autofill 禁止浏览器自动填充表单字段 Chrome
标签服务是一个较为通用的基础业务服务，比如博客系统对文章加标签、社交网络中为好友添加印象、收藏的歌曲贴标签方便整理等等。 其主要提供两类接口： 标签实体的管理/查询：负责标签实体的 CRUD 标签关联的管理/查询：将外部业务实体与标签建立/删除关联，根据外部业务实体 id 查询标签集 RDB 实现 基于关系型数据库的实现是最容易的，并且上大多数应用也是这样做的。 建立 tag 表，其中包含了 tag 的基础属性，例如 name、description 等 建立 tag_rel 关联表，其中主要包含了 object_id、tag_id 管理服务（创建/更新/删除）的实现非常容易；根据 object_id 查询其对应的标签集也很容易实现： SELECT tag_rel.tag_id, tag_rel.object_id, tag.name FROM tag_rel LEFT JOIN tag ON tag_rel.tag_id = tag.tag_id WHERE tag_rel.object_id = '2db775c1d2174a8c67fc39b86c3fc168' 问题 .... 标签服务实现漫谈 数据库
###为什么要使用 HTTPS 当我们使用 HTTP 协议时，传输的数据是不安全的，因为所有在客户端和服务端往来的数据都是明文： * 第三方可以获取到真实数据 * 第三方可以篡改数据 * 第三方可以冒充服务端或客户端 为了解决这些问题，需要在 HTTP 协议中加入一个安全机制，由此并产生了 HTTPS，我们可以认为 HTTPS = HTTP + TLS/SSL。TLS/SSL 的引入解决了安全问题，而上层应用协议还是 HTTP。 ###历史 SSL（Secure Sockets Layer）中文称作“安全套接层”，TLS（Transport Layer Security），中文称作“传输层安全协议”。 1. 1994 年，网景（NetScape）公司设计了 SSL 1.0 2. 1995 年，SSL 2.0，存在严重漏洞 3. 1996 年，SSL 3.0，得到大规模应用 4. 1999 年，IETF 对 SSL 进行标准化，发布了 TLS 1.0 5. 2006 年和 2008 年，TLS 进行了两次升级，分别为 TLS 1.1 和 TLS 1.2 在应用层，我们习惯将两者并称 TL.... 理解 HTTPS 原理，SSL/TLS 协议 编程语言
本文我们会探索两个问题： 1. 网站是应该选择 www 开头的域名作为用户入口还是应该使用不带 www 的域名（裸域）？ 2. Cookie-free 是什么？为什么很重要？ ###www 开头的域名 国内外大多数知名站点都是使用带 www 的二级域名作为用户入口，其中有通过 301 将裸域重定向到 www 二级域名的，也有通过 302 的（较少）。 为什么这些大站（流量大/子域名众多）都要使用带 www 的域名呢，主要原因应该有以下几点： * 对用户来说识别度高，带了 www 后（即使不加 http://）用户就知道这是一个可以用浏览器打开的 URL * 避免将 Cookie 设置在裸域上（后面我们会讨论这样做的坏处） * 在其他地方引用带 www 的 URL 更容易被识别（比如会自动加上链接） 以上主要是对大站来说，我们经常使用的小站（流量小/子域名较少）入口很多是不带 www 的（两者都允许以及类似 Twitter 这样的个例除外），这样做原因应该主要只有一点： * 域名更短，突出简约的个性，特别是一些个性后缀的域名不带 www 时更有利于用户记忆 ###301 or 302...... www 开头的域名和 Cookie-free Cookie-free
D 的个人博客