第一版：

package com.michaelssss;

import java.util.ArrayList;
import java.util.List;

/**
 * @author michaelssss
 * @since 2017/12/7
 */
public class SimpleMap<T, P> {
    private List<Pair<T, P>>[] buckets;

    public SimpleMap() {
        buckets = new ArrayList[64];
    }

    public void put(T key, P value) {
        int hashCode = key.hashCode();
        if (buckets[(hashCode % 64)] == null || buckets[(hashCode % 64)].isEmpty()) {
            buckets[(hashCode % 64)] = new ArrayList<>();
            buckets[(hashCode % 64)].add(new Pair<>(key, value));
        } else {
            boolean found = false;
            for (Pair<T, P> pair : buckets[(hashCode % 64)]) {
                if (pair.key.equals(key)) {
                    pair.value = value;
                    found = true;
                }
            }
            if (!found) {
                buckets[(hashCode % 64)].add(new Pair<>(key, value));
            }
        }
    }

    public P get(T t) {
        P value = null;
        int hashCode = t.hashCode();
        if (null == buckets[(hashCode % 64)] || buckets[(hashCode % 64)].isEmpty()) {
            return null;
        } else {
            for (Pair<T, P> pair : buckets[(hashCode % 64)]) {
                if (pair.key.equals(t)) {
                    value = pair.value;
                    break;
                }
            }
        }
        return value;
    }

    private static class Pair<T, P> {
        T key;
        P value;

        Pair(T key, P value) {
            this.key = key;
            this.value = value;
        }
    }
}

 

 

第二版（加入resize操作）：

package com.michaelssss;

import java.util.ArrayList;
import java.util.List;

/**
 * @author michaelssss
 * @since 2017/12/7
 */
public class SimpleMap<T, P> {
    private List<Pair<T, P>>[] buckets;
    private float loadfactory = 0.75f;
    private int bucketSize;
    private int count;

    public SimpleMap() {
        bucketSize = 64;
        buckets = new ArrayList[64];
    }

    public SimpleMap(int initSize) {
        bucketSize = initSize;
        buckets = new ArrayList[initSize];
    }

    public SimpleMap(int initSize, float loadfactory) {
        this(initSize);
        this.loadfactory = loadfactory;
    }

    public void put(T key, P value) {
        int hashCode = key.hashCode();
        if (buckets[(hashCode % bucketSize)] == null || buckets[(hashCode % bucketSize)].isEmpty()) {
            buckets[(hashCode % bucketSize)] = new ArrayList<>();
            buckets[(hashCode % bucketSize)].add(new Pair<>(key, value));
            count++;
        } else {
            boolean found = false;
            for (Pair<T, P> pair : buckets[(hashCode % bucketSize)]) {
                if (pair.key.equals(key)) {
                    pair.value = value;
                    found = true;
                }
            }
            if (!found) {
                buckets[(hashCode % bucketSize)].add(new Pair<>(key, value));
                count++;
            }
        }
        if (loadfactory * count > bucketSize) {
            resize();
        }
    }

    private void resize() {
        int newBucketSeize = bucketSize * 2;
        List<Pair<T, P>>[] buckets = new ArrayList[newBucketSeize];
        for (List<Pair<T, P>> bucket : this.buckets) {
            if (null != bucket) {
                for (Pair<T, P> pair : bucket) {
                    int hashCode = pair.key.hashCode();
                    if (null == buckets[hashCode % newBucketSeize]) {
                        buckets[hashCode % newBucketSeize] = new ArrayList<>();
                    }
                    buckets[hashCode % newBucketSeize].add(pair);
                }
            }
        }
        this.buckets = buckets;
        this.bucketSize = newBucketSeize;
    }

    public P get(T t) {
        P value = null;
        int hashCode = t.hashCode();
        if (null == buckets[(hashCode % bucketSize)] || buckets[(hashCode % bucketSize)].isEmpty()) {
            return null;
        } else {
            for (Pair<T, P> pair : buckets[(hashCode % bucketSize)]) {
                if (pair.key.equals(t)) {
                    value = pair.value;
                    break;
                }
            }
        }
        return value;
    }

    private final static class Pair<T, P> {
        T key;
        P value;

        Pair(T key, P value) {
            this.key = key;
            this.value = value;
        }
    }
}

 

1.无论何种方式部署，一定要设置delay=-1

2.dubbo调用的序列化有可能不是同步的，即当你远程获取一些信息时候，如果反序列化时间较长，你读取对象信息的时候会直接报空指针异常

3.dubbo是网络连接，无论如何都应该降低调用次数，设计接口的时候最好是batchget或者是做Client部分做Proxy缓存

4.最好将Dubbo的重试机制干掉。。。快速失败，并在Client处做记录，已经遇到过因为Dubbo接口响应慢，多次重试导致直接Provider打爆

Redis当对象存储系统

先来展示一段我司日常常见代码:

……………………

Abc = redisTemplate.opsValues().get(“******”);

if(null==Abc){

abc=………………一堆逻辑

redisTemplate.opsValues().set(“******”,Abc);

}

Return Abc;

 

从逻辑上来说这段代码并没有错误

但这样最终导致的结果是把所有外部的压力都转移到了redis上来了，极有可能导致把redis打爆，从而击穿数据库导致整个系统崩溃

Redis当集群内存用

另一种情况是，redis当共享内存用：

比如我们的zuul部件，每次都把用户的请求完整的set进redis，然后当下一个同session的转发进来后去redis去get，具体表现是redis看到日志是每当一个请求进来会出发两位数到三位数的redis请求（流量极端放大），尽管是zuul部件本身做到了无状态，但其实是用了redis做了共享状态。

这样依旧是把所有压力都放在了redis上面。引发问题更糟糕的是，我们的session内容存了太大的对象redis的并发能力遭到了限制，在少量用户下就已经会引发内部系统的崩溃。

总结一下：

正确的姿势是redis类似与一个单机系统里面不同进程的buffer/channel，在考虑上网络IO的重量级后，我们应该尽可能减少进程之间的通信，在这里的语境下应该是减少集群内之间的通信，从而避免把buffer/channel本身给弄挂了。

在第一种用法下，其实应该是将Abc的状态保存在redis但是Abc本身应该要存在当前结点上，这样就改变了集群内部通过redis传递对象，转而是传递信息了，比如我用时间作为Abc的特征，那么集群内部只需要传递特征时间就能够保持集群内部操作的幂等性，从原有的可能几kb的通讯变为几bit的通讯

第二种用法下，优化的手段就要更多了，首先第一点是减少session保存的数据，将不同业务之间的session分割开来减少session的大小。接着将请求按照一致性hash原理，同一个请求只从zuul集群的同一台服务器走，将保存的信息转换成本地内存，或者将用户-》集群的映射关系存入redis从而减少redis的使用量。

整个系统分为三个部分：

原始数据

包装成商品后数据

客户持有列表数据

原有设计是每一次客户获取客户持有列表数据都会从包装成商品之后的数据获取数据（包装成商品之后原有的原始数据的属性会有可能被商城变更）

因为Dubbo的方便性让人不自觉的就忽略掉了远程调用的IO是很重的

原有设计时，每个客户第一次访问会从原始数据+包装后商品数据进行遍历，然后存入redis，接着以后调用直接走redis。

当天上线后，发现原始数据的系统直接出现了百万次调用且因为代码笔误全部打到了数据库上，灰度环境紧急回滚

事后分析可能有以下几个原因：

1、不知道因何系统无法从redis上读取数据，都直接开始了调用

2、因为原有的设计可能流量只会放大N倍，但因为配合其他系统上线，增加了两段逻辑，流量放大为3N倍

3、因为dubbo的超时重试机制，流量再次放大三倍，直接导致整个系统的崩溃

优化方案：

将远程调用转为本地调用

1、给dubbo接口增加Proxy，作为本地缓存

2、定期从原始数据平台拉去数据，保证数据的一致性

3、其他逻辑保持不变

这样将网络请求变为本地内存调用，比较好的解决了因系统流量放大导致的系统雪崩情况

技术栈的选型:

1. 人员成本
2. 使用成本
3. 改造成本

第一点指的是在市场上找一个熟悉当前技术栈的人是否困难, 一般情况下开源软件的人员比较容易找, 但也仅限于初级人员, 若是需要到较深层次的改写或者应用, 无论任何技术栈都非常困难(多数情况下情景退化成自研)

第二点是用起来这个组件好不好用,简不简单,比如EJB这种在绑定WebSphere战车上,用起来非常舒服.或者你整体都是Spring,沿用了Spring技术套件也会很舒服

第三点指当前选型与原有选型发生冲突要进行改造改动的返回 ,当然如果一个项目真心是完全敏捷开发这个完全不需要考虑.大部分情况下,比如从Dubbo切换至SpringCloud,从SOAP到Probuf(比如当前我司….),冲突厉害了还要做技术演进方案…如果无法演进就更痛苦成本就变高

私货:

个人偏好充血模型,但是以Spring开发的WEB应用都是贫血模型, 所以技术栈还可能影响开发习惯和偏好

自行设计消息队列

需求描述

1. 能够存储消息
2. 能够获取消息
3. 能够区分topic

接口设计

时序图

消息入队:

消息出队:

拓展点:

完全依赖Storage作为拓展点,若是单机消息队列,则直接实现单机Storage

若是集群存储则实现集群Storage

若是分布式存储则实现分布式的Storage

所有上层操作依赖Storage接口

已经默认实现了的单机Storage

分别是CompressFileStorage, SplitFileStorage

分别实现场景是,单消息单文件存储

多消息单文件存储

Github地址:

https://github.com/michaelssss/MyQueue

从一个比赛题目来看业务设计应该如何设计

先说,数据库设计如下

题目:

要求设计一个接口getBlogList(userid,int begin,int offset)

返回blog以下数据

{

“Blog”:[

“blogid”:xxx, //博客id

“createtime”:xxx, //博客创建时间，需最新的在最前羰

“readflag”:1/0, //当前用户的已读状态

“praiselist”:[“xxx”,”yyyy”,”zzz”,……], //当前博客的点赞人例表

“commentlist”:[“xxx”,”yyy”,”zzz”,……] //当前博客的评论人例表

]

“Blog”:[

“blogid”:xxx,

“createtime”:xxx,

“readflag”:1/0,

“praiselist”:[“xxx”,”yyyy”,”zzz”,……],

“commentlist”:[“xxx”,”yyy”,”zzz”,……]

]

……

}

模拟数据数量级为百万级别

让我们来看看再不考虑内存占用下的最优解:

所有表预存至本地内存

提前对所有数据做好计算,到时候单纯的根据bloguid就可以在N(1)的时间下拿到数据和对象

十条数据

耗时1ms

输出压缩json大小23KB

两百条数据

耗时16ms

输出压缩json大小485KB

接下来把点赞详情和阅读详情操作给去除

十条数据:

耗时低于ms级别

输出json压缩大小低于kb级别

两百条数据:

耗时2ms

输出压缩json大小11KB

接下来把点赞数和阅读数加入操作中

十条数据:

耗时1ms

输出压缩json大小低于KB数量级

两百条数据

耗时10ms

输出压缩json大小17KB

问题在于,现实系统中,博文数量及点赞数一般的比这些模拟数据要大得多,且不可能完全load进内存中.

在上面的最优解中,瓶颈在于输出的数据量,也就是网络IO瓶颈

单次map是内存操作,一般是ns级别

网络通信的的时间一般是ms级别

彼此相差三个数量级,那么可以猜想,无论如何优化系统的响应时间也应该与这次测试相差三个数量级甚至更多.

那么以上题目放在实际系统场景中问题是什么呢?

1. 每次请求时候才去做数据的计算统计排序(因为不允许preload就不允许启动的时候计算完毕并启用)
2. 单次请求的数据没有区分重点和无关紧要点(你看个列表为啥要详情),导致单次查询数据量爆炸,不仅是查询的量过多,而且输出的量也是继续攀升,导致网络IO负担明显

 

针对以上,从业务上应该做如下规避:

1. 输出列表时候不应该把点赞和评论的详情带上,而应该只需要统计量,减少输出结果的
2. 单独维护一个列表,用于排序条件,比较使用<K.V>系统避免在业务代码中动态的进行计算(减少每次请求的遍历时间);
3. 如点赞数和评论数也可以维护在<K.V>系统内,数据库只是一个序列化的仓库
4. 只有用户需要查看点赞详情和评论详情的时候才去请求查询