INGNIGHT的专栏

【代码】计数器限流。

https://ipads.se.sjtu.edu.cn/pub/coursesScheduleCSDI lectures are taken on Thursday 3-5.We will update the schedule soon.Week 0:IntroductionLec.0:Feb. 27Slides:IntroductionWeek 1:System Design Princeple ILec.1:Mar. 5Slides:Overview ...

作者：穆尼奥链接：https://zhuanlan.zhihu.com/p/138199791来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。内存模型用线程有两个作用：提高性能，利用多核。 更优雅的构造代码。在本课程实验中，我们并不要求使用线程以极尽性能，只要求程序的正确性。对锁的使用也一样，不要求细粒度的加锁以提升性能，可以大范围加锁以简化代码。内存模型中主要提到了多线程执行时，代码运行的顺序性。主要结论是，单个线程内的可以保证执行效果和代码.

转载：https://zhuanlan.zhihu.com/p/73917931开始先考虑下边的问题。let s = "js"console.log(s.length)s= "亮"console.log(s.length)s = " "console.log(s.length)我们知道 length 就是字符串的字符数，所以输出的依次是 2，1，1，对吗？探索一我们知道，计算机里只能存 0 和 1，换言之，只能存数字，而我们现在在屏幕上看到的文字只是将数字对应到图形而已

转载：https://mp.weixin.qq.com/s/QidAD9OuVdEXFqxRMPx5lQ1. 常见概念在合理应用缓存前，需要了解缓存领域里相关的几个常用术语：1）缓存命中：表示数据能够从缓存中获取，不需要回源；2）Cache miss：表示没有命中缓存，如果缓存内存中还有内存空间的话，会将数据加入到缓存中；3）存储成本：当没有命中缓存时，回源获取后会将数据放置到存储中，整个将数据放置到存储空间所需要的时间以及空间称之为存储成本；4）缓存失效：当源数据发生变更后，意味着

转载：https://coolshell.cn/articles/17416.html#comments看到好些人在写更新缓存数据代码时，先删除缓存，然后再更新数据库，而后续的操作会把数据再装载的缓存中。然而，这个是逻辑是错误的。试想，两个并发操作，一个是更新操作，另一个是查询操作，更新操作删除缓存后，查询操作没有命中缓存，先把老数据读出来后放到缓存中，然后更新操作更新了数据库。于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还一直这样脏下去了。我不知道为什么这么多人用的都是这个逻辑，

转载：https://blog.csdn.net/winx_coder/article/details/764079761.基本信息书名：自制搜索引擎作者：山田浩之，末永匡译者：胡屹书籍类型：源码剖析类2.内容概述本书主要讲解了：如何从零开始，编写一个基于“倒排索引（Inverted Index）”的“全文检索引擎（FullText Search Engine）”。最终的成果，相当于一个迷你版的Apache Lucene。（注意：是自制Lucene，而不是调用Lucene）.

理论的优点在于清晰简洁、易于理解，但缺点就是高度抽象化，省略了很多细节，导致在将理论应用到实践时，由于各种复杂情况，可能出现误解和偏差，CAP 理论也不例外。如果我们没有意识到这些关键的细节点，那么在实践中应用 CAP 理论时，就可能发现方案很难落地。而且当谈到数据一致性时，CAP、ACID、BASE 难免会被我们拿出来讨论，原因在于这三者都是和数据一致性相关的理论，如果不仔细理解三者之间的差别，则可能会陷入一头雾水的状态，不知道应该用哪个才好。今天，我来讲讲CAP 的具体细节，简单对比一下 ACI

A、如果cache.set如果失败，会造成脏数据假设ABCD串行执行，第一个执行成功，第二个执行失败。ABD会造成脏数据当同时有很多用户设置一个key，假设第8～9行之前做了一个setUser， 第9行设置了一个不对的一个数值...

AP.java，Application Programpackage com.agan.dtp.xa;import java.sql.Connection;import java.sql.DriverManager;import java.sql.SQLException;/** * @author 阿甘 * @see https://study.163.com/course/courseMain.htm?courseId=1209367806&share=2&amp...

Protocol Buffers这是要多快好省的建设社会主义啊。理想还是要有的嘛，这里我就来介绍一个向“理想”迈进的GRPC。GRPC首先满足二进制和跨语言这两条，二进制说明压缩效率高，跨语言说明更灵活。但是又是二进制，又是跨语言，这就相当于两个人沟通，你不但说方言，还说缩略语，人家怎么听懂呢？所以，最好双方弄一个协议约定文件，里面规定好双方沟通的专业术语，这样沟通就顺畅多了。对于GRPC来讲，二进制序列化协议是Protocol Buffers。首先，需要定义一个协议文件.proto。我们还

C++漏斗限流法// g++ bucket_limit.cpp -std=c++11#include<iostream>#include<sys/time.h>#include<unordered_map>#include<map>#include <unistd.h>using namespace std;// 漏斗限流class BucketLimit {public: BucketLimit(int rat

全局ID 要做到幂等性的交易接口，需要有一个唯一的标识，来标志交易是同一笔交易。而这个交易ID由谁来分配是一件比较头疼的事。因为这个标识要能做到全局唯一。如果由一个中心系统来分配，那么每一次交易都需要找那个中心系统来。 这样增加了程序的性能开销。如果由上游系统来分配，则可能会导致可能会出现分配ID重复了的问题。因为 上游系统可能会是一个集群，它们同时承担相同的工作。为了不产生分配冲突，我们需要使用一个不会冲突的算法，比如使用UUID这样冲突非常小的算法。但UUID的问题是，它的字符串占用的空间比较大

1. 计算容量在解决问题之前，要先计算一下海量数据需要占多大的容量。常见的单位换算如下：1 byte = 8 bit 1 KB = 210 byte = 1024 byte ≈ 10^3 byte 1 MB = 220 byte ≈ 10^6 byte 1 GB = 230 byte ≈ 10^9 byte 1 亿 = 10^81 个整数占 4 byte，1 亿个整数占 4*10^8 byte ≈ 400 MB。2. 拆分可以将海量数据拆分到多台机器上和拆分到多个文件上：如果数

虽然我们可以通过各种手段来提升存储系统的性能，但在某些复杂的业务场景下，单纯依靠存储系统的性能提升不够的，典型的场景有：需要经过复杂运算后得出的数据，存储系统无能为力例如，一个论坛需要在首页展示当前有多少用户同时在线，如果使用 MySQL 来存储当前用户状态，则每次获取这个总数都要“count(*)”大量数据，这样的操作无论怎么优化 MySQL，性能都不会太高。如果要实时展示用户同时在线数，则 MySQL 性能无法支撑。读多写少的数据，存储系统有心无力绝大部分在线业务都是读多写少。例如，微博、淘

关系数据库经过几十年的发展后已经非常成熟，强大的 SQL 功能和 ACID 的属性，使得关系数据库广泛应用于各式各样的系统中，但这并不意味着关系数据库是完美的，关系数据库存在如下缺点。关系数据库存储的是行记录，无法存储数据结构以微博的关注关系为例，“我关注的人”是一个用户 ID 列表，使用关系数据库存储只能将列表拆成多行，然后再查询出来组装，无法直接存储一个列表。关系数据库的 schema 扩展很不方便关系数据库的表结构 schema 是强约束，操作不存在的列会报错，业务变化时扩充列也比较麻烦，

随着互联网进入下半场，对于“人”、“货”、“场”三个核心元素的要求越来越高，随着数据量和流量的爆发式增长，传统的人工运营方式已经很难适应当下如此复杂的业务场景，如何精细、准确、高效、智能地联系三者成为各个平台系统越来越关注的点，于是基于千人千面个性化的推荐系统成为各个业务场景必不可少的一环。本文主要介绍在电商场景下，关于个性化推荐系统的架构方面的介绍，考虑到篇幅，其他推荐系统相关的算法大数据方面技术例如特征工程、模型训练部署等会在另外文章中介绍。先给出系统的总体技术架构图，具体模块后面详细介绍。

前言截止到2015年7月，微信每月活跃用户约5.49亿，朋友圈每天的发表量（包括赞和评论）超过10亿，浏览量超过100亿。得益于4G网络的发展，以上数据仍有很快的增长，而且相对于PC互联网时代，移动互联网时代的峰值要来得更加凶猛。比如，2015年元月的流量到了平时的2倍，而峰值则达到了平时峰值的2倍，相当于平时正常流量的5倍，这对整个系统的考验是很残酷的。本次分享将简单介绍微信后台团队的开发模式、微信朋友圈的架构以及在性能上的一些工作，供各位参考。基本介绍微信朋友圈后台研发团队由三位工程师组

设计 Pastebin.com (或者 Bit.ly)https://github.com/donnemartin/system-design-primer/blob/master/solutions/system_design/pastebin/README-zh-Hans.md注意: 为了避免重复，当前文档会直接链接到系统设计主题的相关区域，请参考链接内容以获得综合的讨论点、权衡和替代方案。设计 Bit.ly- 是一个类似的问题，区别是 pastebin 需要存储的是 paste 的内容，.

1.架构设计https://github.com/donnemartin/system-design-primer/blob/master/solutions/system_design/social_graph/README.md

一、雪崩原因1.服务过载，服务提供者不可用硬件故障，部分机器挂掉 用户大量请求，流量突增，资源不足 程序bug 缓存击穿2.重试加大流量用户重试 代码逻辑重试3.服务调用者不可用同步等待造成的资源耗尽代码：https://github.com/ibinarytree/koala/blob/master/example/hystrix_example/main.go...

一、架构设计如上图题解：https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md#%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E7%9A%84%E9%9D%A2%E8%AF%95%E9%A2%98%E5%92%8C%E8%A7%A3%E7%AD%94二、leetcode单机版本题目https://blog.csdn.net/INGNIGHT/art...

一、CAPC（Consistency）：一致性，是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据A:（Availability）：可用性，是指快速获取数据。非故障节点在合理的时间内返回合理的响应（不是错误和超时的响应）P（Tolerance of Network Partition）：分区容忍性，是...