zoukankan      html  css  js  c++  java
  • 分布式系统下的全局id生成策略分析

    对于分布式系统而言,意味着会有很多个instance会并发的生成很多业务数据,比如订单。不同的机房、不同的机器、不同的应用实例会同时生成。所以,如何生成一个好用的全局id并不是一个简单的uuid就能够搞定的事情。事实上,数据库内置的序列(oracle)或者自增机制(mysql)也无法满足需求。虽然可以设置gap,但是他无法做到扩展时基本不受影响。

    同时,纯粹意义上的uuid(指的是逻辑上,而非技术上的uuid)或者整数自增在大型应用中,很有可能是不合适的,因为很多时候,我们真正需要的ID是有一定意义的,比如反应了业务类型,日期,甚至客户编号。当然纯粹意义上的业务无关的uuid也不是一无是处,比如说在图片分享应用中,id可能就确实不需要什么含义,在社交应用中,可能id也确实不需要意义。

    但是,很多应用比如saas、大型分布式企业应用比如金融交易系统、电商交易系统,完全无意义的uuid很有可能使得成本增加很多。因为不同于社交应用,企业应用的业务模式通常是用户自己的数据相关的,而不是没有倾向性的。所以,在设计uuid的过程中,我们其实针对场景进行细化,整理了一下如下的草图:

    电商类的,可能需要进一步细化是搜索的还是交易处理的、资金处理的。总的来说,就是整个平台内需要根据实际情况进行分类:

    1、纯UUID的;

    2、业务前缀+UUID;

    3、业务前缀+用户+UUID;

    对于saas的,可能还会出现

    4:APPID+业务前缀+用户+UUID;

    日期部分,看情况,可能有,也可以没有。

    为了保证长度不超过32位,UUID我们采用的是snowflake的算法实现参考。

    采用一刀切的方法,通常来说,这个架构师是经验欠缺的。

  • 相关阅读:
    模态对话框可能导致程序崩溃
    C++实现将字符串循环左移n个位置
    Android Gallery图片显示和文字提示及Menu 菜单
    android代码实现ScaleAnimation
    Android系统内存管理的问题
    android打电话发短信
    android开发之屏幕设置
    输入法
    黄金周
    气筒
  • 原文地址:https://www.cnblogs.com/zhjh256/p/6898403.html
Copyright © 2011-2022 走看看