观察者模式

当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知它的依赖对象。观察者模式属于行为型模式。

主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。

何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。

如何解决：使用面向对象技术，可以将这种依赖关系弱化。

优点： 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。

缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

Spring Boot 之事件（Event）

Spring的事件通知机制是一项很有用的功能，使用事件机制我们可以将相互耦合的代码解耦，从而方便功能的修改与添加。本文我来学习并分析一下Spring中事件的原理。

举个例子，假设有一个添加评论的方法，在评论添加成功之后需要进行修改redis缓存、给用户添加积分等等操作。当然可以在添加评论的代码后面假设这些操作，但是这样的代码违反了设计模式的多项原则：单一职责原则、迪米特法则、开闭原则。一句话说就是耦合性太大了，比如将来评论添加成功之后还需要有另外一个操作，这时候我们就需要去修改我们的添加评论代码了。

在以前的代码中，我使用观察者模式来解决这个问题。不过Spring中已经存在了一个升级版观察者模式的机制，这就是监听者模式。通过该机制我们就可以发送接收任意的事件并处理。

Spring 官方文档翻译如下：

ApplicationContext 通过 ApplicationEvent 类和 ApplicationListener 接口进行事件处理。如果将实现 ApplicationListener 接口的 bean 注入到上下文中，则每次使用 ApplicationContext 发布 ApplicationEvent 时，都会通知该 bean。本质上，这是标准的观察者设计模式。

Spring的事件（Application Event）其实就是一个观察者设计模式，一个 Bean 处理完成任务后希望通知其它 Bean 或者说一个Bean 想观察监听另一个Bean的行为。

Spring 事件只需要几步：

自定义事件，继承 ApplicationEvent
定义监听器，实现 ApplicationListener 或者通过 @EventListener 注解到方法上
定义发布者，通过 ApplicationEventPublisher

实际代码：

创建event文件夹

并创建event object类和handle类，一个handle类可以对应多个object类。

@Data
@AllArgsConstructor
@NoArgsConstructor
public class EverydayStatisticEventObject {

  private Integer id;

  private String os;

  private String proxy;

  private StatisticEventType statisticEventType;

}

创建枚举类处理不同的事件类型，运用观察者模式

public enum StatisticEventType {
   
  //注册数统计
  REGISTER_COUNTER,
  //活跃数统计
  ACTIVE_COUNTER,
  //裂变数统计
  FISSION_COUNTER,
  //播放数统计
  PLAYED_COUNTER,
  //广告点击数统计
  ADCLICK_COUNTER;

  private StatisticEventType() {
  }
}

在事务service类中注入

@Autowired
  private ApplicationEventPublisher publisher;

处理完相应的业务逻辑后，调取publish操作，将事务发布出去

其一

public LoginLog increaseLoginLog(String ip, int uid, String username) {
    User user = mixinsService.getUser(uid);
    LoginLog loginLog = new LoginLog();
    loginLog.setLoginIp(ip);
    loginLog.setLoginTime(new Date());
    loginLog.setUid(uid);
    loginLog.setUsername(username);
    loginLog.setProxy(user.getProxy());
    loginLog.setChannel(user.getChannel());
    loginLog.setUserType(user.getUserType());
    loginLog.setOs(user.getOs());
    LoginLog log = loginLogRepository.save(loginLog);
    
    //发布事件
    publisher.publishEvent(new EverydayStatisticEventObject(log.getUid(), log.getOs(), log.getProxy(),StatisticEventType.ACTIVE_COUNTER));
    ChannelDailyDataManager.fireEvent(new UserActiveEvent(user.getChannel()));
    return log;
  }

Google Guava Cache缓存

Google Guava Cache是一种非常优秀本地缓存解决方案，提供了基于容量，时间和引用的缓存回收方式。基于容量的方式内部实现采用LRU算法，基于引用回收很好的利用了Java虚拟机的垃圾回收机制。其中的缓存构造器CacheBuilder采用构建者模式提供了设置好各种参数的缓存对象，缓存核心类LocalCache里面的内部类Segment与jdk1.7及以前的ConcurrentHashMap非常相似，都继承于ReetrantLock，还有六个队列，以实现丰富的本地缓存方案。

Guava Cache与ConcurrentMap的区别

Guava Cache与ConcurrentMap很相似，但也不完全一样。最基本的区别是ConcurrentMap会一直保存所有添加的元素，直到显式地移除。相对地，Guava Cache为了限制内存占用，通常都设定为自动回收元素。在某些场景下，尽管LoadingCache 不回收元素，它也是很有用的，因为它会自动加载缓存。

//bitmap的偏移量offset生产,offset越大，占用内存越多，所以以每日第一个id作为minid，作为被减数
//使用guava cache缓存机制获取最小id,设置过期时间为每一天，每天清空一次
private LoadingCache<String, Integer> minId = CacheBuilder.newBuilder().expireAfterWrite(1L, TimeUnit.DAYS).build(new CacheLoader<String, Integer>() {
    @Override
    public Integer load(String s) throws Exception {
      Date date = LocalDate.parse(StringUtils.substringAfter(s, "@")).toDate();
      if (ACTIVE_COUNTER.startsWith(s)) {
        LoginLog loginLog = loginLogRepository.getTopByLoginTimeBeforeOrderByIdDesc(date);
        if (loginLog != null) {
          return loginLog.getId();
        }
      } else if (PLAYED_COUNTER.startsWith(s)) {
        ViewHistory viewHistory = viewHistoryRepository.getTopByViewtimeBeforeOrderByIdDesc(date);
        if (viewHistory != null) {
          return viewHistory.getId();
        }
      } else if (ADCLICK_COUNTER.startsWith(s)) {
        AdvClickHistory advClickHistory = advClickHistoryRepository.getTopByCreateTimeBeforeOrderByIdDesc(date);
        if (advClickHistory != null) {
          return advClickHistory.getId();
        }
      }
      return 0;
    }
  });

用Redis bitmap统计活跃用户、留存

对于个int型的数来说,若用来记录id,则只能记录一个,而若转换为二进制存储,则可以表示32个,空间的利用率提升了32倍.对于海量数据的处理,这样的存储方式会节省很多内存空间.对于未登陆的用户,可以使用Hash算法,把对应的用户标识哈希为一个数字id.对于一亿个数据来说,我们也只需要1000000000/8/1024/1024大约12M空间左右.

而Redis已经为我们提供了SETBIT的方法，使用起来非常的方便，我们在item页面可以不停地使用SETBIT命令，设置用户已经访问了该页面，也可以使用GETBIT的方法查询某个用户是否访问。最后通过BITCOUNT统计该网页每天的访问数量。

优点: 占用内存更小，查询方便，可以指定查询某个用户，对于非登陆的用户，可能不同的key映射到同一个id，否则需要维护一个非登陆用户的映射，有额外的开销。

//使用观察者模式，根据不同的type来判断不同的事务
public String progressChanged(EverydayStatisticEventObject registerEventObject) {
    String Type = "";
    StatisticEventType eventType = registerEventObject.getStatisticEventType();
    switch (eventType) {
      case REGISTER_COUNTER:
        Type = REGISTER_COUNTER;
        break;
      case ACTIVE_COUNTER:
        Type = ACTIVE_COUNTER;
        break;
      case FISSION_COUNTER:
        Type = FISSION_COUNTER;
        break;
      case PLAYED_COUNTER:
        Type = PLAYED_COUNTER;
        break;
      case ADCLICK_COUNTER:
        Type = ADCLICK_COUNTER;
        break;
      default:
        break;
    }
    return Type;
  }

  //事件监听器
  //异步
  @EventListener
  @Async
  public void registerCountEvent(EverydayStatisticEventObject registerEventObject) {


    String date = LocalDate.now().toString(STATISTIC_DATE_FMT);
    String type = progressChanged(registerEventObject);
    
    //数据库主键id 减去当天第一个id 这样每天的偏移量都是从一开始可以有效减少偏移量对内存的占用。
    int offset = registerEventObject.getId() + 1 - minId.getUnchecked(StringUtils.join(type, "@", date));

    String key = StringUtils.join(STATISTIC_CACHE_KEY_PREFIX, type,
      date, ":", registerEventObject.getOs());


    setBitmap(offset, key);

    String proxyKey = StringUtils.join(STATISTIC_CACHE_KEY_PREFIX, type,
      date, ":", registerEventObject.getProxy(), ":", registerEventObject.getOs());

    setBitmap(offset, proxyKey);

        
       /* redisTemplate.execute((RedisCallback) connection -> {
            Long count = connection.bitCount(key.getBytes());

            log.info("key={},count = {}，offset={}",key,count,offset);
            return true;
        });

        redisTemplate.execute((RedisCallback) connection -> {
            Long count = connection.bitCount(proxyKey.getBytes());

            log.info("proxyKey={},count = {},offset={}",proxyKey,count,offset);
            return true;
        });*/
  }

private void setBitmap(int offset, String key) {

    byte[] bitKey = key.getBytes();

    redisTemplate.execute((RedisCallback) connection -> {
      boolean exists = connection.getBit(bitKey, offset);
      if (!exists) {
        connection.setBit(bitKey, offset, true);
        //设置过期时间 每天的数据统计 只保留2天
        connection.expire(bitKey, 60L * 60 * 24 * 2);  //2 days
        return true;
      }
      return false;
    });
  }

来源：CSDN

作者：雪中鱼01

链接：https://blog.csdn.net/songkai558919/article/details/104627238

标签

观察者模式

社交平台

系统设计

仿微博社交平台系统设计[四]--使用springevent事件驱动模型(观察者模式)结合redis bitmap 运用 实现每日数据统计

观察者模式

Spring Boot 之事件（Event）

实际代码：

Google Guava Cache缓存

Guava Cache与ConcurrentMap的区别

用Redis bitmap统计活跃用户、留存

仿微博社交平台系统设计[四]--使用springevent事件驱动模型(观察者模式)结合redis bitmap 运用实现每日数据统计