来源： JS异常： Uncaught RangeError: Maximum call stack size exceeded_wenpy的博客-CSDN博客_uncaught rangeerror: maximum call stack size excee

今天被一个bug弄得头大…！！！！！！！

找了无数资料…网上说是递归函数的原因

https://blog.csdn.net/qq_30100043/article/details/72642205

还是未能解决问题，继续找！！！！

最后在 https://blog.csdn.net/FansUnion/article/details/73801346 大哥的博文中找到灵感！！！

删除清除Chrome缓存和Cookie

删除清除Chrome缓存和Cookie

删除清除Chrome缓存和Cookie

来源： c# – 如何不使用.Compile()从MemberExpression获取属性值？ – IT工具网

我在尝试不使用.compile（）从表达式树中获取对象的值时遇到问题
目标很简单。

var userModel = new UserModel { Email = "John@Doe.com"};

给我问题的方法是这样的。

private void VisitMemberAccess(MemberExpression expression, MemberExpression left)
{
    var key = left != null ? left.Member.Name : expression.Member.Name;
    if (expression.Expression.NodeType.ToString() == "Parameter")
    {
        // add the string key
        _strings.Add(string.Format("[{0}]", key));
    }
    else
    {
        // add the string parameter
        _strings.Add(string.Format("@{0}", key));

        // Potential NullReferenceException
        var val = (expression.Member as FieldInfo).GetValue((expression.Expression as ConstantExpression).Value);

        // add parameter value
        Parameters.Add("@" + key, val);
    }
}

我做的测试很简单

[Test]  // PASS
public void ShouldVisitExpressionByGuidObject ()
{
    // Setup
    var id = new Guid( "CCAF57D9-88A4-4DCD-87C7-DB875E0D4E66" );
    const string expectedString = "[Id] = @Id";
    var expectedParameters = new Dictionary<string, object> { { "@Id", id } };

    // Execute
    var actualExpression = TestExpression<UserModel>( u => u.Id == id );
    var actualParameters = actualExpression.Parameters;
    var actualString = actualExpression.WhereExpression;

    // Test
    Assert.AreEqual( expectedString, actualString );
    CollectionAssert.AreEquivalent( expectedParameters, actualParameters );
}

[Test]  // FAIL [System.NullReferenceException : Object reference not set to an instance of an object.]
public void ShouldVisitExpressionByStringObject ()
{
    // Setup
    var expectedUser = new UserModel {Email = "john@doe.com"};

    const string expectedString = "[Email] = @Email";
    var expectedParameters = new Dictionary<string, object> { { "@Email", expectedUser.Email } };

    // Execute
    var actualExpression = TestExpression<UserModel>( u => u.Email == expectedUser.Email );
    var actualParameters = actualExpression.Parameters;
    var actualString = actualExpression.WhereExpression;

    // Assert
    Assert.AreEqual( expectedString, actualString );
    CollectionAssert.AreEquivalent( expectedParameters, actualParameters );
}

我应该注意到改变

var val = (expression.Member as FieldInfo).GetValue((expression.Expression as ConstantExpression).Value);

到

var val = Expression.Lambda( expression ).Compile().DynamicInvoke().ToString();

将允许测试通过，但是此代码需要在ios上运行，因此不能使用.Compile()

TLDR；
只要不使用Emit或Compile，反射就可以使用。在这个问题中，值是为FieldInfo提取的，但不是为PropertyInfo提取的。一定要两样都买得到。

if ((expression.Member as PropertyInfo) != null)
{
    // get the value from the PROPERTY

}
else if ((expression.Member as FieldInfo) != null)
{
    // get the value from the FIELD
}
else
{
    throw new InvalidMemberException();
}

长卷本
所以这些评论给了我正确的方向。我有点费劲地想弄到房产信息，但最后，我想到了这个。

private void VisitMemberAccess(MemberExpression expression, MemberExpression left)
{
    // To preserve Case between key/value pairs, we always want to use the LEFT side of the expression.
    // therefore, if left is null, then expression is actually left. 
    // Doing this ensures that our `key` matches between parameter names and database fields
    var key = left != null ? left.Member.Name : expression.Member.Name;

    // If the NodeType is a `Parameter`, we want to add the key as a DB Field name to our string collection
    // Otherwise, we want to add the key as a DB Parameter to our string collection
    if (expression.Expression.NodeType.ToString() == "Parameter")
    {
        _strings.Add(string.Format("[{0}]", key));
    }
    else
    {
        _strings.Add(string.Format("@{0}", key));

        // If the key is being added as a DB Parameter, then we have to also add the Parameter key/value pair to the collection
        // Because we're working off of Model Objects that should only contain Properties or Fields,
        // there should only be two options. PropertyInfo or FieldInfo... let's extract the VALUE accordingly
        var value = new object();
        if ((expression.Member as PropertyInfo) != null)
        {
            var exp = (MemberExpression) expression.Expression;
            var constant = (ConstantExpression) exp.Expression;
            var fieldInfoValue = ((FieldInfo) exp.Member).GetValue(constant.Value);
            value = ((PropertyInfo) expression.Member).GetValue(fieldInfoValue, null);

        }
        else if ((expression.Member as FieldInfo) != null)
        {
            var fieldInfo = expression.Member as FieldInfo;
            var constantExpression = expression.Expression as ConstantExpression;
            if (fieldInfo != null & constantExpression != null)
            {
                value = fieldInfo.GetValue(constantExpression.Value);
            }
        }
        else
        {
            throw new InvalidMemberException();
        }

        // Add the Parameter Key/Value pair.
        Parameters.Add("@" + key, value);
    }
}

实际上，如果Member.NodeType是一个Parameter，那么我将把它用作一个SQL字段。[FieldName]
否则，我将它用作SQL参数@FieldName。倒过来我知道。
如果Member.NodeType不是参数，那么我检查它是modelField还是modelProperty。从那里，我得到适当的值，并将键/值对添加到字典中，用作SQL参数。
最终的结果是我构建了一个类似于

SELECT * FROM TableName WHERE
[FieldName] = @FieldName

然后传递参数

var parameters = new Dictionary<string, object> Parameters;
parameters.Add("@FieldName", "The value of the field");

来源： js如何简单实现汉字转成拼音的功能 – 小小邪 – 博客园

　　最近项目需要一个功能，实现汉字转拼音功能，具体比如说输入一个“你好”，同时带出对应拼音“NiHao”，在此做一下记录

1、首先引入两个文件

    <script src="jquery.min.js"></script>
    <script src="Convert_Pinyin.js"></script>

2、html设计

 <body>
        <div>         
             输入名称：<input type="text" id="chinaName"  onBlur="ConvertName()" />  <br/>  
             全写拼音：<input type="text" id="fullName" /> <br/> 
             简写拼音：<input type="text" id="easyName" /> <br/> 
        </div>    
 </body>

3、js方法

<script>
       var ConvertName = function(){    
            var chinaName = $('#chinaName').val();    
            //获取全写拼音（调用js中方法）        
            var fullName = pinyin.getFullChars(chinaName);
            //获取简写拼音（调用js中方法）
            var easyName = pinyin.getCamelChars(chinaName);    
            //给两个文本框赋值    
            $('#fullName').val(fullName);
            $('#easyName').val(easyName);
       }
</script>

4、实现效果

5、整体demo

<!doctype html>
<html>
    <head>
        <meta charset="utf-8">
        <title>如何实现汉字转拼音功能</title>
    </head>
    <script src="jquery.min.js"></script>
    <script src="Convert_Pinyin.js"></script>
    <script>            
        var ConvertName = function(){    
            var chinaName = $('#chinaName').val();    
            //获取全写拼音（调用js中方法）        
            var fullName = pinyin.getFullChars(chinaName);
            //获取简写拼音（调用js中方法）
            var easyName = pinyin.getCamelChars(chinaName);    
            //给两个文本框赋值    
            $('#fullName').val(fullName);
            $('#easyName').val(easyName);
        }
        
    </script>
    <body>
        <div>         
             输入名称：<input type="text" id="chinaName"  onBlur="ConvertName()" />  <br/>  
             全写拼音：<input type="text" id="fullName" /> <br/> 
             简写拼音：<input type="text" id="easyName" /> <br/> 
        </div>    
    </body>
</html>

6、汉字转拼音js下载路径：

链接：https://pan.baidu.com/s/1NZ4noIgHv2HSzZW6yBRTxA    密码：2kv1

来源： 『JWT』，你必须了解的认证登录方案 – 风的姿态 – 博客园

JWT 全称是 JSON Web Token，是目前非常流行的跨域认证解决方案，在单点登录场景中经常使用到。

有些人觉得它非常好用，用了它之后就不用在服务端借助 redis 实现认证过程了，但是，还有一部分人认为它生来就有缺陷，根本不能用。

这是为什么呢？

传统的认证方式

从一个登录场景说起

你平时用过那么多网站和 APP，其中有很多都是需要登录的吧，那咱们就选一个场景出来说说。

以一个电商系统为例，如果你想要下单，首先需要注册一个账号，拥有了账号之后，需要输入用户名（比如手机号或邮箱）、密码完成登录过程。之后你在一段时间内再次进入系统，是不需要输入用户名和密码的，只有在连续长时间不登录的情况下（例如一个月没登录过）访问系统，才需要再次输入用户名和密码。

对于那些使用频率很高的网站或应用，通常是很长时间都不需要输入密码的，以至于你在换了一台电脑或者一部手机之后，一些经常使用的网站或 APP 的密码都不记得了。

早期的 Cookie-Session 认证方式

早期互联网以 web 为主，客户端是浏览器 ，所以 Cookie-Session 方式是早期最常用的认证方式，直到现在，一些 web 网站依然用这种方式做认证。

认证过程大致如下：

1. 用户输入用户名、密码或者用短信验证码方式登录系统；
2. 服务端验证后，创建一个 Session 信息，并且将 SessionID 存到 cookie，发送回浏览器；
3. 下次客户端再发起请求，自动带上 cookie 信息，服务端通过 cookie 获取 Session 信息进行校验；

但是为什么说它是传统的认证方式，因为现在人手一部智能手机，很多人都不用电脑，平时都是使用手机上的各种 APP，比如淘宝、拼多多等。
在这种潮流之下，传统的 Cookie-Session 就遇到了一些问题：
1、首先，Cookie-Session 只能在 web 场景下使用，如果是 APP 呢，APP 可没有地方存 cookie。
现在的产品基本上都同时提供 web 端和 APP 两种使用方式，有点产品甚至只有 APP。

2、退一万步说，你做的产品只支持 web，也要考虑跨域问题， 但Cookie 是不能跨域的。
拿天猫商城来说，当你进入天猫商城后，会看到顶部有天猫超市、天猫国际、天猫会员这些菜单。而点击这些菜单都会进入不同的域名，不同的域名下的 cookie 都是不一样的，你在 A 域名下是没办法拿到 B 域名的 cookie 的，即使是子域也不行。

3、如果是分布式服务，需要考虑 Session 同步问题。
现在的互联网网站和 APP 基本上都是分布式部署，也就是服务端不止一台机器。当某个用户在页面上进行登录操作后，这个登录动作必定是请求到了其中某一台服务器上。你的身份信息得保存下来吧，传统方式就是存 Session。

接下来，问题来了。你访问了几个页面，这时，有个请求经过负载均衡，路由到了另外一台服务器（不是你登录的那台）。当后台接到请求后，要检查用户身份信息和权限，于是接口开始从从 Session 中获取用户信息。但是，这台服务器不是当时登录的那台，并没存你的 Session ，这样后台服务就认为你是一个非登录的用户，也就不能给你返回数据了。

所以，为了避免这种情况的发生，就要做 Session 同步。一台服务器接收到登录请求后，在当前服务器保存 Session 后，也要向其他几个服务器同步。

4、cookie 存在 CSRF（跨站请求伪造）的风险。 跨站请求伪造，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。CSRF 利用的是网站对用户网页浏览器的信任。简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（比如购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户发起的操作。
比如说我是一个黑客，我发现你经常访问的一个技术网站存在 CSRF 漏洞。发布文章支持 html 格式，进而我在 html 中加入一些危险内容，例如

 <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

假设 src 指向的地址是一个你平时用的购物网站的付款地址（当然只是举例，真正的攻击可没这么简单），如果你之前登录过并且标识你身份信息的 cookie 已经保存下来了。当你刷到我发布的这篇文章的时候，img 标签一加载，这个 CSRF 攻击就会起作用，在你不知情的情况下向这个网站付款了。

Cookie-Session 改造版

由于传统的 Cookie-Session 认证存在诸多问题，那可以把上面的方案改造一下。
1、改造 Cookie 既然 Cookie 不能在 APP 等非浏览器中使用，那就不用 cookie 做客户端存储，改用其他方式。
改成什么呢？
web 中可以使用 local storage，APP 中使用客户端数据库，这样既能这样就实现了跨域，并且避免了 CSRF 。

2、服务端也不存 Session 了，把 Session 信息拿出来存到 Redis 等内存数据库中，这样即提高了速度，又避免了 Session 同步问题；

经过改造之后变成了如下的认证过程：

1. 用户输入用户名、密码或者用短信验证码方式登录系统；
2. 服务端经过验证，将认证信息构造好的数据结构存储到 Redis 中，并将 key 值返回给客户端；
3. 客户端拿到返回的 key，存储到 local storage 或本地数据库；
4. 下次客户端再次请求，把 key 值附加到 header 或者 请求体中；
5. 服务端根据获取的 key，到 Redis 中获取认证信息；

下面两张图分别演示了首次登录和非首次登录的过程。

经过一顿猛如虎的改造，解决了传统 Cookie-Session 方式存在的问题。这种改造需要开发者在项目中自行完成。改造起来肯定是费时费力的，而且还有可能存在漏洞。

JWT 出场

这时，JWT 就可以上场了，JWT 就是一种Cookie-Session改造版的具体实现，让你省去自己造轮子的时间，JWT 还有个好处，那就是你可以不用在服务端存储认证信息（比如 token），完全由客户端提供，服务端只要根据 JWT 自身提供的解密算法就可以验证用户合法性，而且这个过程是安全的。

如果你是刚接触 JWT，最有疑问的一点可能就是： JWT 为什么可以完全依靠客户端(比如浏览器端)就能实现认证功能，认证信息全都存在客户端，怎么保证安全性？

JWT 数据结构

JWT 最后的形式就是个字符串，它由头部、载荷与签名这三部分组成，中间以「.」分隔。像下面这样：

头部

头部以 JSON 格式表示，用于指明令牌类型和加密算法。形式如下，表示使用 JWT 格式，加密算法采用 HS256，这是最常用的算法，除此之外还有很多其他的。

{
  "alg": "HS256",
  "typ": "JWT"
}

对应上图的红色 header 部分，需要 Base64 编码。

载荷

用来存储服务器需要的数据，比如用户信息，例如姓名、性别、年龄等，要注意的是重要的机密信息最好不要放到这里，比如密码等。

{
  "name": "古时的风筝",
  "introduce": "英俊潇洒"
}

另外，JWT 还规定了 7 个字段供开发者选用。

• iss (issuer)：签发人
• exp (expiration time)：过期时间
• sub (subject)：主题
• aud (audience)：受众
• nbf (Not Before)：生效时间
• iat (Issued At)：签发时间
• jti (JWT ID)：编号

这部分信息也是要用 Base64 编码的。

签名

签名有一个计算公式。

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  Secret
)

使用HMACSHA256算法计算得出，这个方法有两个参数，前一个参数是 （base64 编码的头部 + base64 编码的载荷）用点号相连，后一个参数是自定义的字符串密钥，密钥不要暴露在客户端，近应该服务器知道。

使用方式

了解了 JWT 的结构和算法后，那怎么使用呢？假设我这儿有个网站。

1、在用户登录网站的时候，需要输入用户名、密码或者短信验证的方式登录，登录请求到达服务端的时候，服务端对账号、密码进行验证，然后计算出 JWT 字符串，返回给客户端。

2、客户端拿到这个 JWT 字符串后，存储到 cookie 或者 浏览器的 LocalStorage 中。

3、再次发送请求，比如请求用户设置页面的时候，在 HTTP 请求头中加入 JWT 字符串，或者直接放到请求主体中。

4、服务端拿到这串 JWT 字符串后，使用 base64的头部和 base64 的载荷部分，通过HMACSHA256算法计算签名部分，比较计算结果和传来的签名部分是否一致，如果一致，说明此次请求没有问题，如果不一致，说明请求过期或者是非法请求。

怎么保证安全性的

保证安全性的关键就是 HMACSHA256 或者与它同类型的加密算法，因为加密过程是不可逆的，所以不能根据传到前端的 JWT 传反解到密钥信息。

另外，不同的头部和载荷加密之后得到的签名都是不同的，所以，如果有人改了载荷部分的信息，那最后加密出的结果肯定就和改之前的不一样的，所以，最后验证的结果就是不合法的请求。

别人拿到完整 JWT 还安全吗

假设载荷部分存储了权限级别相关的字段，强盗拿到 JWT 串后想要修改为更高权限的级别，上面刚说了，这种情况下是肯定不会得逞的，因为加密出来的签名会不一样，服务器可能很容易的判别出来。

那如果强盗拿到后不做更改，直接用呢，那就没有办法了，为了更大程度上防止被强盗盗取，应该使用 HTTPS 协议而不是 HTTP 协议，这样可以有效的防止一些中间劫持攻击行为。

有同学就要说了，这一点也不安全啊，拿到 JWT 串就可以轻松模拟请求了。确实是这样，但是前提是你怎么样能拿到，除了上面说的中间劫持外，还有什么办法吗？

除非强盗直接拿了你的电脑，那这样的话，对不起，不光 JWT 不安全了，其他任何网站，任何认证方式都不安全。

虽然这样的情况很少，但是在使用 JWT 的时候仍然要注意合理的设置过期时间，不要太长。

一个问题

JWT 有个问题，导致很多开发团队放弃使用它，那就是一旦颁发一个 JWT 令牌，服务端就没办法废弃掉它，除非等到它自身过期。有很多应用默认只允许最新登录的一个客户端正常使用，不允许多端登录，JWT 就没办法做到，因为颁发了新令牌，但是老的令牌在过期前仍然可用。这种情况下，就需要服务端增加相应的逻辑。

常用的 JWT 库

JWT 官网列出了各种语言对应的库，其中 Java 的如下几个。

以 java-jwt为例。

1、引入对应的 Maven 包。

<dependency>
    <groupId>com.auth0</groupId>
    <artifactId>java-jwt</artifactId>
    <version>3.10.3</version>
</dependency>

2、在登录时，调用 create 方法得到一个令牌，并返回给前端。

public static String create(){
  try {
    Algorithm algorithm = Algorithm.HMAC256("secret");
    String token = JWT.create()
      .withIssuer("auth0")
      .withSubject("subject")
      .withClaim("name","古时的风筝")
      .withClaim("introduce","英俊潇洒")
      .sign(algorithm);
    System.out.println(token);
    return token;
  } catch (JWTCreationException exception){
    //Invalid Signing configuration / Couldn't convert Claims.
    throw exception;
  }
}

3、登录成功后，再次发起请求的时候将 token 放到 header 或者请求体中，服务端对 token 进行验证。

public static Boolean verify(String token){
  try {
    Algorithm algorithm = Algorithm.HMAC256("secret");
    JWTVerifier verifier = JWT.require(algorithm)
      .withIssuer("auth0")
      .build(); //Reusable verifier instance
    DecodedJWT jwt = verifier.verify(token);
    String payload = jwt.getPayload();
    String name = jwt.getClaim("name").asString();
    String introduce = jwt.getClaim("introduce").asString();
    System.out.println(payload);
    System.out.println(name);
    System.out.println(introduce);
    return true;
  } catch (JWTVerificationException exception){
    //Invalid signature/claims
    return false;
  }
}

4、用 create 方法生成 token，并用 verify 方法验证一下。

public static void main(String[] args){
  String token = create();
  Boolean result = verify(token);
  System.out.println(result);
}

得到下面的结果

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0.ooQ1K_XyljjHf34Nv5iJvg1MQgVe6jlphxv4eeFt8pA
eyJzdWIiOiJzdWJqZWN0IiwiaW50cm9kdWNlIjoi6Iux5L-K5r2H5rSSIiwiaXNzIjoiYXV0aDAiLCJuYW1lIjoi5Y-k5pe255qE6aOO562dIn0
古时的风筝
英俊潇洒
true

使用 create 方法创建的 JWT 串可以通过验证。

而如果我将 JWT 串中的载荷部分，两个点号中间的部分修改一下，然后再调用 verify 方法验证，会出现 JWTVerificationException 异常，不能通过验证。

这位英俊潇洒的少年，如果觉得还不错的话，给个推荐可好！

公众号「古时的风筝」，Java 开发者，全栈工程师，bug 杀手，擅长解决问题。
一个兼具深度与广度的程序员鼓励师，本打算写诗却写起了代码的田园码农！坚持原创干货输出，你可选择现在就关注我，或者看看历史文章再关注也不迟。长按二维码关注，跟我一起变优秀！

来源： jQuery字母大小写转换函数 – 柚子茶丶 – 博客园

来源： 阿里的秒杀系统是怎么设计的？ – 敖丙 – 博客园

点赞再看，养成习惯，微信搜一搜【三太子敖丙】关注这个互联网苟且偷生的工具人。

本文 GitHub https://github.com/JavaFamily 已收录，有一线大厂面试完整考点、资料以及我的系列文章。

背景

我之前写过一个秒杀系统的文章不过有些许瑕疵，所以我准备在之前的基础上进行二次创作，不过让我决心二创秒杀系统的原因是我最近面试了很多读者，动不动就是秒杀系统把我整蒙蔽了，我懵的主要是秒杀系统的细节大家都不知道，甚至不知道电商公司一个秒杀系统的组成部分。

我之前在某电商公司就是做电商活动的，所以这样的场景和很多解决方案我是比较清楚的，那我就从我自身去带着大家看看一个秒杀的设计细节以及中间各种解决方案的利弊，以下就是我设计的秒杀系统，几乎涵盖了市面上所有秒杀的实现细节：

正文

首先设计一个系统之前，我们需要先确认我们的业务场景是怎么样子的，我就带着大家一起假设一个场景好吧。

我们现场要卖1000件下面这个婴儿纸尿裤，然后我们根据以往这样秒杀活动的数据经验来看，目测来抢这100件纸尿裤的人足足有10万人。（南极人打钱！）

你一听，完了呀，这我们的服务器哪里顶得住啊！说真的直接打DB肯定挂，但是别急嘛，有暖男敖丙在，任何系统我们开始设计之前我们都应该去思考会出现哪些问题？这里我罗列了几个非常经典的问题：

问题

高并发：

是的高并发这个是我们想都不用想的一个点，一瞬间这么多人进来这不是高并发什么时候是呢？

是吧，秒杀的特点就是这样时间极短、 瞬间用户量大。

正常的店铺营销都是用极低的价格配合上短信、APP的精准推送，吸引特别多的用户来参与这场秒杀，爽了商家苦了开发呀。

秒杀大家都知道如果真的营销到位，价格诱人，几十万的流量我觉得完全不是问题，那单机的Redis我感觉3-4W的QPS还是能顶得住的，但是再高了就没办法了，那这个数据随便搞个热销商品的秒杀可能都不止了。

大量的请求进来，我们需要考虑的点就很多了，缓存雪崩，缓存击穿，缓存穿透这些我之前提到的点都是有可能发生的，出现问题打挂DB那就很难受了，活动失败用户体验差，活动人气没了，最后背锅的还是开发。

超卖：

但凡是个秒杀，都怕超卖，我这里举例的只是尿不湿，要是换成100个MacBook Pro，商家的预算经费卖100个可以赚点还可以造势，结果你写错程序多卖出去200个，你不发货用户投诉你，平台封你店，你发货就血亏，你怎么办？ （没事看了敖丙的文章直接不怕）

那最后只能杀个开发祭天解气了，秒杀的价格本来就低了，基本上都是不怎么赚钱的，超卖了就恐怖了呀，所以超卖也是很关键的一个点。

恶意请求：

你这么低的价格，假如我抢到了，我转手卖掉我不是血赚？就算我不卖我也不亏啊，那用户知道，你知道，别的别有用心的人（黑客、黄牛…）肯定也知道的。

那简单啊，我知道你什么时候抢，我搞个几十台机器搞点脚本，我也模拟出来十几万个人左右的请求，那我是不是意味着我基本上有80%的成功率了。

真实情况可能远远不止，因为机器请求的速度比人的手速往往快太多了，在贵州的敖丙我每年回家抢高铁票都是秒光的，我也不知道有没有黄牛的功劳，我要Diss你，黄牛。杰伦演唱会门票抢不到，我也Diss你。

Tip：科普下，小道消息了解到的，黄牛的抢票系统，比国内很多小公司的系统还吊很多，架构设计都是顶级的，我用顶配的服务加上顶配的架构设计，你还想看演唱会？还想回家？

不过不用黄牛我回家都难，我们云贵川跟我一样要回家过年的仔太多了555！

链接暴露：

前面几个问题大家可能都很好理解，一看到这个有的小伙伴可能会比较疑惑，啥是链接暴露呀？

相信是个开发同学都对这个画面一点都不陌生吧，懂点行的仔都可以打开谷歌的开发者模式，然后看看你的网页代码，有的就有URL，但是我写VUE的时候是事件触发然后去调用文件里面的接口看源码看不到，但是我可以点击一下查看你的请求地址啊，不过你好像可以对按钮在秒杀前置灰。

不管怎么样子都有危险，撇开外面的所有的东西你都挡住了，你卖这个东西实在便宜得过分，有诱惑力，你能保证开发不动心？开发知道地址，在秒杀的时候自己提前请求。。。（开发：怎么TM又是我）

数据库：

每秒上万甚至十几万的QPS（每秒请求数）直接打到数据库，基本上都要把库打挂掉，而且你服务不单单是做秒杀的还涉及其他的业务，你没做降级、限流、熔断啥的，别的一起挂，小公司的话可能全站崩溃404。

反正不管你秒杀怎么挂，你别把别的搞挂了对吧，搞挂了就不是杀一个程序员能搞定的。

程序员：我TM好难啊！

问题都列出来了，那怎么设计，怎么解决这些问题就是接下去要考虑的了，我们对症下药。

我会从我设计的秒杀系统从上到下去给大家介绍我们正常电商秒杀系统在每一层做了些什么，每一层存在的问题，难点等。

我们从前端开始：

前端

秒杀系统普遍都是商城网页、H5、APP、小程序这几项。

在前端这一层其实我们可以做的事情有很多，如果用node去做，甚至能直接处理掉整个秒杀，但是node其实应该属于后端，所以我不讨论node Service了。

资源静态化：

秒杀一般都是特定的商品还有页面模板，现在一般都是前后端分离的，页面一般都是不会经过后端的，但是前端也要自己的服务器啊，那就把能提前放入cdn服务器的东西都放进去，反正把所有能提升效率的步骤都做一下，减少真正秒杀时候服务器的压力。

秒杀链接加盐：

我们上面说了链接要是提前暴露出去可能有人直接访问url就提前秒杀了，那又有小伙伴要说了我做个时间的校验就好了呀，那我告诉你，知道链接的地址比起页面人工点击的还是有很大优势。

我知道url了，那我通过程序不断获取最新的北京时间，可以达到毫秒级别的，我就在00毫秒的时候请求，我敢说绝对比你人工点的成功率大太多了，而且我可以一毫秒发送N次请求，搞不好你卖100个产品我全拿了。

那这种情况怎么避免？

简单，把URL动态化，就连写代码的人都不知道，你就通过MD5之类的摘要算法加密随机的字符串去做url，然后通过前端代码获取url后台校验才能通过。

这个只能防止一部分没耐心继续破解下去的黑客，有耐心的人研究出来还是能破解，在电商场景存在很多这样的羊毛党，那怎么做呢？

后面我会说。

限流：

限流这里我觉得应该分为前端限流和后端限流。

物理控制：

大家有没有发现没到秒杀前，一般按钮都是置灰的，只有时间到了，才能点击。

这是因为怕大家在时间快到的最后几秒秒疯狂请求服务器，然后还没到秒杀的时候基本上服务器就挂了。

这个时候就需要前端的配合，定时去请求你的后端服务器，获取最新的北京时间，到时间点再给按钮可用状态。

按钮可以点击之后也得给他置灰几秒，不然他一样在开始之后一直点的。

你敢说你们秒杀的时候不是这样的？

前端限流：这个很简单，一般秒杀不会让你一直点的，一般都是点击一下或者两下然后几秒之后才可以继续点击，这也是保护服务器的一种手段。

后端限流：秒杀的时候肯定是涉及到后续的订单生成和支付等操作，但是都只是成功的幸运儿才会走到那一步，那一旦100个产品卖光了，return了一个false，前端直接秒杀结束，然后你后端也关闭后续无效请求的介入了。

Tip：真正的限流还会有限流组件的加入例如：阿里的Sentinel、Hystrix等。我这里就不展开了，就说一下物理的限流。

我们卖1000件商品，请求有10W，我们不需要把十万都放进来，你可以放1W请求进来，然后再进行操作，因为秒杀对于用户本身就是黑盒的，所以你怎么做的他们是没感知的，至于为啥放1W进来，而不是刚好1000，是因为会丢掉一些薅羊毛的用户，至于怎么判断，后面的风控阶段我会说。

Nginx：

Nginx大家想必都不陌生了吧，这玩意是高性能的web服务器，并发也随便顶几万不是梦，但是我们的Tomcat只能顶几百的并发呀，那简单呀负载均衡嘛，一台服务几百，那就多搞点，在秒杀的时候多租点流量机。

Tip：据我所知国内某大厂就是在去年春节活动期间租光了亚洲所有的服务器，小公司也很喜欢在双十一期间买流量机来顶住压力。

这样一对比是不是觉得你的集群能顶很多了。

恶意请求拦截也需要用到它，一般单个用户请求次数太夸张，不像人为的请求在网关那一层就得拦截掉了，不然请求多了他抢不抢得到是一回事，服务器压力上去了，可能占用网络带宽或者把服务器打崩、缓存击穿等等。

风控

我可以明确的告诉大家，前面的所有措施还是拦不住很多羊毛党，因为他们是专业的团队，他们可以注册很多账号来薅你的羊毛，而且不用机器请求，就用群控，操作几乎跟真实用户一模一样。

那怎么办，是不是无解了？

这个时候就需要风控同学的介入了，在请求到达后端之前，风控可以根据账号行为分析出这个账号机器人的概率大不大，我现在负责公司的某些特殊系统，每个用户的行为都是会送到我们大数据团队进行分析处理，给你打上对应标签的。

那黑客其实也有办法：养号

他们去黑市买真实用户有过很多记录的账号，买到了还不闲着，帮他们去购物啥的，让系统无法识别他们是黑号还是真实用户的号。

怎么办？

通杀！是的没有办法，只能通杀了，通杀的意思就是，我们通过风管分析出来这个用户是真实用户的概率没有其他用户概率大，那就认为他是机器了，丢弃他的请求。

之前的限流我们放进来10000个请求，但是我们真正的库存只有1000个，那我们就算出最有可能是真实用户的1000人进行秒杀，丢弃其他请求，因为秒杀本来就是黑盒操作的，用户层面是无感知的，这样设计能让真实的用户买到东西，还可以减少自己被薅羊毛的概率。

风控可以说是流量进入的最后一道门槛了，所以很多公司的风控是很强的，蚂蚁金服的风控大家如果了解过就知道了，你的资金在支付宝被盗了，他们是能做到全款补偿是有原因的。

后端

服务单一职责：

设计个能抗住高并发的系统，我觉得还是得单一职责。

什么意思呢，大家都知道现在设计都是微服务的设计思想，然后再用分布式的部署方式。

也就是我们下单是有个订单服务，用户登录管理等有个用户服务等等，那为啥我们不给秒杀也开个服务，我们把秒杀的代码业务逻辑放一起。

单一职责的好处就是就算秒杀没抗住，秒杀库崩了，服务挂了，也不会影响到其他的服务。（高可用）

Redis集群：

之前不是说单机的Redis顶不住嘛，那简单多找几个兄弟啊，秒杀本来就是读多写少，那你们是不是瞬间想起来我之前跟你们提到过的，Redis集群，主从同步、读写分离，我们还搞点哨兵，开启持久化直接无敌高可用！

库存预热：

秒杀的本质，就是对库存的抢夺，每个秒杀的用户来你都去数据库查询库存校验库存，然后扣减库存，撇开性能因数，你不觉得这样好繁琐，对业务开发人员都不友好，而且数据库顶不住啊。

开发：你tm总算为我着想一次了。

那怎么办？

我们都知道数据库顶不住但是他的兄弟非关系型的数据库Redis能顶啊！

那不简单了，我们要开始秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去，让整个流程都在Redis里面去做，然后等秒杀介绍了，再异步的去修改库存就好了。

但是用了Redis就有一个问题了，我们上面说了我们采用主从，就是我们会去读取库存然后再判断然后有库存才去减库存，正常情况没问题，但是高并发的情况问题就很大了。

**多品几遍！！！**就比如现在库存只剩下1个了，我们高并发嘛，4个服务器一起查询了发现都是还有1个，那大家都觉得是自己抢到了，就都去扣库存，那结果就变成了-3，是的只有一个是真的抢到了，别的都是超卖的。咋办？

事务：

Redis本身是支持事务的，而且他有很多原子命令的，大家也可以用LUA，还可以用他的管道，乐观锁他也知支持。

限流&降级&熔断&隔离：

这个为啥要做呢，不怕一万就怕万一，万一你真的顶不住了，限流，顶不住就挡一部分出去但是不能说不行，降级，降级了还是被打挂了，熔断，至少不要影响别的系统，隔离，你本身就独立的，但是你会调用其他的系统嘛，你快不行了你别拖累兄弟们啊。

消息队列（削峰填谷）：

一说到这个名词，很多小伙伴就知道了，对的MQ，你买东西少了你直接100个请求改库我觉得没问题，但是万一秒杀一万个，10万个呢？服务器挂了，程序员又要背锅的。

秒杀就是这种瞬间流量很高，但是平时又没有流量的场景，那消息队列完全契合这样的场景了呀，削峰填谷。

Tip：可能小伙伴说我们业务达不到这个量级，没必要。但是我想说我们写代码，就不应该写出有逻辑漏洞的代码，至少以后公司体量上去了，别人一看居然不用改代码，一看代码作者是敖丙？有点东西！

你可以把它放消息队列，然后一点点消费去改库存就好了嘛，不过单个商品其实一次修改就够了，我这里说的是某个点多个商品一起秒杀的场景，像极了双十一零点。

数据库

数据库用MySQL只要连接池设置合理一般问题是不大的，不过一般大公司不缺钱而且秒杀这样的活动十分频繁，我之前所在的公司就是这样秒杀特卖这样的场景一直都是不间断的。

单独给秒杀建立一个数据库，为秒杀服务，表的设计也是竟可能的简单点，现在的互联网架构部署都是分库的。

至于表就看大家怎么设计了，该设置索引的地方还是要设置索引的，建完后记得用explain看看SQL的执行计划。（不了解的小伙伴也没事，MySQL章节去康康）

分布式事务

这为啥我不放在后端而放到最后来讲呢？

因为上面的任何一步都是可能出错的，而且我们是在不同的服务里面出错的，那就涉及分布式事务了，但是分布式事务大家想的是一定要成功什么的那就不对了，还是那句话，几个请求丢了就丢了，要保证时效和服务的可用可靠。

所以TCC和最终一致性其实不是很适合，TCC开发成本很大，所有接口都要写三次，因为涉及TCC的三个阶段。

最终一致性基本上都是靠轮训的操作去保证一个操作一定成功，那时效性就大打折扣了。

大家觉得不那么可靠的**两段式（2PC）和三段式（3PC）**就派上用场了，他们不一定能保证数据最终一致，但是效率上还算ok。

总结

到这里我想我已经基本上把该考虑的点还有对应的解决方案也都说了一下，不知道还有没有没考虑到的，但是就算没考虑到我想我这个设计，应该也能撑住一个完整的秒杀流程。

最后大家再看看这个秒杀系统或许会有新的感悟，是不是一个系统真的没有大家想的那么简单，而且我还是有漏掉的细节，这是一定的。

秒杀这章我脑细胞死了很多，考虑了很多个点，最后还是出来了，忍不住给自己点赞！

总结

我们玩归玩，闹归闹，别拿面试开玩笑。

秒杀不一定是每个同学都会问到的，至少肯定没Redis基础那样常问，但是一旦问到，大家一定要回答到点上。

至少你得说出可能出现的情况，需要注意的情况，以及对于的解决思路和方案，因为这才是一个coder的基本素养，这些你不考虑你也很难去进步。

最后就是需要对整个链路比较熟悉，注意是一个完整的链路，前端怎么设计的呀，网关的作用呀，怎么解决Redis的并发竞争啊，数据的同步方式呀，MQ的作用啊等等，相信你会有不错的收获。

不知道这是一次成功还是失败的二创，我里面所有提到的技术细节我都写了对应的文章，大家可以关注我去历史文章看看，天色已晚，我溜了。

絮叨

另外，敖丙把自己的面试文章整理成了一本电子书，共 1630页！目录如下，还有我复习时总结的面试题以及简历模板

return false

来源： jquery的$.each如何退出循环和退出本次循环 – 咖啡无眠 – 博客园

JQuery中each类似于JavaScript的for循环
但不同于for循环的是在each里面不能使用break结束循环，也不能使用continue来结束本次循环，想要实现类似的功能就只能用return,
break           用return false
continue      用return true

来源： 当前上下文中不存在名称”__o” – XOYOZO

经常会看到这样似错非错的提示：

当前上下文中不存在名称”__o”

The name ‘__o’ does not exist in the current context

实际上，我没有定义任何名为 __o 的变量。

发生这种情况的原因可能是使用了类似如下的代码：

为了在设计界面的 <%= %> 代码块中提供智能感知，ASP.NET（VB 或 C#）会自动生成一个名为“__o”的临时变量，这在页面编译器看到第一个 <%= %> 块时就完成了。但是在这里，<%= %> 块在 if 中出现，所以当关闭 if 后再使用 <%= %> 时，变量超出了定义的范围。

解决方法：在页面的早期添加一个虚表达式。例如：<%= “” %>。这将不会呈现任何内容，并且它将确保在任何潜在的 if（或其他范围界定）语句之前，在 Render 方法中将 __o 声明为顶级。

当然还有一种治标不治本的方法就是隐藏这些错误提示（这并不影响程序正常运行）：

点击错误列表面板左上角的过滤器按钮，CS0103，其中包含错误代码：当前上下文中不存在名称”__o”，这些错误将不再显示，您仍然可以有其他 IntelliSense 错误和警告。

有趣的依赖问题…… VS2015.3,.NET45将Microsoft.Owin从3.0.0更新到3.0.1(跟踪此更新是问题 – 想要安装https://www.nuget.org/packages/IdentityServer3.AccessTokenValidation/) 它在IIS Express上本地工作 但发布到Azure网站:(我直接从VS删除目标上的其他文件).重新启动并删除了a

来源： c# – 无法将文件或程序集Microsoft.Owin 3.0.0加载到3.0.1 – 程序园

<dependentAssembly>
   <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
   <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />   
</dependentAssembly>

来源： SQL Server 取日期时间 – 一技赢 – 博客园

在本文中，GetDate()获得的日期由两部分组成，分别是今天的日期和当时的时间： Select GetDate()
用DateName()就可以获得相应的年、月、日，然后再把它们连接起来就可以了：

Select Datename(year,GetDate())+’-‘+Datename
(month,GetDate())+’-‘+Datename(day,GetDate())

另外，DateName()还可以获得到小时、时间、秒、星期几、第几周，分别如下：

Select Datename(hour,GetDate())
Select Datename(minute,GetDate())
Select Datename(second,GetDate())
Select Datename(weekDay,GetDate())
Select Datename(week,GetDate())

SQL中的日期类型DateTime的默认格式就是yyyy-mm-dd hh:mi:ss: mmm，可大多数的情况我们只想得到他的日期部分，而不许要后面的时间。上一篇中提到用Datename()函数来截取拼接出不包含时间部分的日期，现在再说一种方法，更加简单的获取到不包含时间的日期！

使用Convert()函数：

select convert(char(10),GetDate(),120) as Date

* 第3个参数就是用来设置日期类型数据的显示样式的，下面介绍几种样式的参数：

100   mm dd yyyy

101   mm/dd/yyyy

102   yyyy.mm.dd

103   dd/mm/yyyy

106   dd mm yyyy

108   hh:mi:ss(时间)

111   yyyy/mm/dd

112   yyyymmdd

120   yyyy-mm-dd

 1 SELECT CONVERT(varchar(100), GETDATE(), 0) 05  9 2011  9:12AM
 2  SELECT CONVERT(varchar(100), GETDATE(), 1) 05/09/11
 3 SELECT CONVERT(varchar(100), GETDATE(), 2) 11.05.09
 4 SELECT CONVERT(varchar(100), GETDATE(), 3) 09/05/11
 5 SELECT CONVERT(varchar(100), GETDATE(), 4) 09.05.11
 6 SELECT CONVERT(varchar(100), GETDATE(), 5) 09-05-11
 7 SELECT CONVERT(varchar(100), GETDATE(), 6) 09 05 11
 8 SELECT CONVERT(varchar(100), GETDATE(), 7) 05 09, 11
 9 SELECT CONVERT(varchar(100), GETDATE(), 8) 09:13:14
10 SELECT CONVERT(varchar(100), GETDATE(), 9) 05  9 2011  9:13:14:670AM
11 SELECT CONVERT(varchar(100), GETDATE(), 10) 05-09-11
12 SELECT CONVERT(varchar(100), GETDATE(), 11) 11/05/09
13 SELECT CONVERT(varchar(100), GETDATE(), 12) 110509
14 SELECT CONVERT(varchar(100), GETDATE(), 13) 09 05 2011 09:13:14:670
15 SELECT CONVERT(varchar(100), GETDATE(), 14) 09:13:14:670
16 SELECT CONVERT(varchar(100), GETDATE(), 20) 2011-05-09 09:13:14
17 SELECT CONVERT(varchar(100), GETDATE(), 21) 2011-05-09 09:13:14.670
18 SELECT CONVERT(varchar(100), GETDATE(), 22) 05/09/11  9:15:33 AM
19 SELECT CONVERT(varchar(100), GETDATE(), 23) 2011-05-09
20 SELECT CONVERT(varchar(100), GETDATE(), 24) 09:15:33
21 SELECT CONVERT(varchar(100), GETDATE(), 25) 2011-05-09 09:15:33.140
22 SELECT CONVERT(varchar(100), GETDATE(), 100) 05  9 2011  9:15AM
23 SELECT CONVERT(varchar(100), GETDATE(), 101) 05/09/2011
24 SELECT CONVERT(varchar(100), GETDATE(), 102) 2011.05.09
25 SELECT CONVERT(varchar(100), GETDATE(), 103) 09/05/2011
26 SELECT CONVERT(varchar(100), GETDATE(), 104) 09.05.2011
27 SELECT CONVERT(varchar(100), GETDATE(), 105) 09-05-2011
28 SELECT CONVERT(varchar(100), GETDATE(), 106) 09 05 2011
29 SELECT CONVERT(varchar(100), GETDATE(), 107) 05 09, 2011
30 SELECT CONVERT(varchar(100), GETDATE(), 108) 09:16:38
31 SELECT CONVERT(varchar(100), GETDATE(), 109) 05  9 2011  9:16:38:543AM
32 SELECT CONVERT(varchar(100), GETDATE(), 110) 05-09-2011
33 SELECT CONVERT(varchar(100), GETDATE(), 111) 2011/05/09
34 SELECT CONVERT(varchar(100), GETDATE(), 112) 20110509
35 SELECT CONVERT(varchar(100), GETDATE(), 113) 09 05 2011 09:17:19:857
36 SELECT CONVERT(varchar(100), GETDATE(), 114) 09:17:19:857
37 SELECT CONVERT(varchar(100), GETDATE(), 120) 2011-05-09 09:17:19
38 SELECT CONVERT(varchar(100), GETDATE(), 121) 2011-05-09 09:17:19.857
39 SELECT CONVERT(varchar(100), GETDATE(), 126) 2011-05-09T09:17:19.857
40 SELECT CONVERT(varchar(100), GETDATE(), 130)  6 ????? ??????? 1432  9:17:19:857AM
41 SELECT CONVERT(varchar(100), GETDATE(), 131)  6/06/1432  9:17:19:857AM