![\"image-20210720183149860\"](\"https://tva1.sinaimg.cn/large/008i3skNgy1gsnlg4wo9tj30te07x0u6.jpg\")
[TOC]
\n\n\nDubbo的扩展点加载来自于JDK的标准SPI(Service Provider Interface)扩展点发现机制，并对其进行加强。
\n
来自Dubbo官网的描述，Dubbo改进了JDK标准SPI，并且解决了一下问题:
\nDubbo约定在扩展类的jar包内，放置扩展点配置文件META-INF/dubbo/接口全限定名，内容为：配置名=扩展实现类全限定名，存在多个实现类时用换行符分割。
\n\nSPI ，全称为Service Provider Interface, 是一种服务发现机制。它通过在
\nClassPath路径下的META-INF/service查找并自动加载实现类。简单来说就是一种动态替换发现机制，接口运行时才发现具体的实现类，只需要在运行前添加一个实现即可，并且将实现描述给JDK即可，这里的描述便是上面提到的
\nMETA-INF/service下的配置。也可以随时对该描述进行修改，完成具体实现的替换。
Java提供了很多SPI，允许第三方为这些接口提供实现；常见的SPI有JDBC、JNDI等。
\n这些SPI接口是由Java来提供的，而SPI的实现则是作为依赖的第三方jar加载进CLASSPATHzhong .
例如：Java提供的java.sql.Driver和MySql实现的com.mysql.cj.jdbc.Driver，并且在META-INF/service下存在该配置:com.mysql.cj.jdbc.Driver
下面简单写个Demo实现看看：
\n我们先提供一个接口
\npackage cc.ccoder.loader;\n\npublic interface DownloadStrategy {\n\n void download();\n}分别提供两个实现类，这两个实现类可以理解成第三方jar中对标准接口的实现。
\npackage cc.ccoder.loader;\n\npublic class HttpDownloadStrategy implements DownloadStrategy{\n @Override\n public void download() {\n System.out.println(\"采用Http下载方式\");\n }\n}package cc.ccoder.loader;\n\npublic class SftpDownloadStrategy implements DownloadStrategy {\n @Override\n public void download() {\n System.out.println(\"采用SFTP方式下载\");\n }\n}在META-INF/services目录下创建一个扩展点配置文件，路径为META-INF/services/接口全限定名称。那么我们这个例子的文件名称是cc.ccoder.loader.DownloadStrategy 并且文件名内容为具体实现类全限定名称。
cc.ccoder.loader.HttpDownloadStrategy\ncc.ccoder.loader.SftpDownloadStrategy写一个测试类通过ServiceLoader加载具体的实现
package cc.ccoder.loader;\n\nimport java.util.ServiceLoader;\n\npublic class JavaSpiLoaderTest {\n public static void main(String[] args) {\n ServiceLoader<DownloadStrategy> serviceLoader = ServiceLoader.load(DownloadStrategy.class);\n //这里会一次实例化所有接口实现\n for (DownloadStrategy downloadStrategy : serviceLoader) {\n downloadStrategy.download();\n }\n }\n}看看输出结果
\n和我们预期一样，会一次实例化所所有接口实现。
\nConnected to the target VM, address: '127.0.0.1:64219', transport: 'socket'\n采用Http下载方式\n采用SFTP方式下载\nDisconnected from the target VM, address: '127.0.0.1:64219', transport: 'socket'\n\nProcess finished with exit code 0上面提到了Java的SPI机制，那么Dubbo的ExtensionLoader则是对SPI的加强。这里我们改造一下上面那个例子并且写一个测试看看。
package cc.ccoder.loader;\n\nimport org.apache.dubbo.common.extension.SPI;\n\n@SPI(\"http\")\npublic interface DownloadStrategy {\n\n void download();\n}在DownloadStrategy接口上添加@SPI注解。
修改META-INF/services的配置文件
http=cc.ccoder.loader.HttpDownloadStrategy\nsftp=cc.ccoder.loader.SftpDownloadStrategy运行一下测试方法
\npackage cc.ccoder.loader;\n\nimport org.apache.dubbo.common.extension.ExtensionLoader;\n\npublic class DubboSpiLoaderTest {\n\n public static void main(String[] args) {\n ExtensionLoader<DownloadStrategy> extensionLoader = ExtensionLoader.getExtensionLoader(DownloadStrategy.class);\n //这里getExtension方法进行加载具体扩展点\n DownloadStrategy downloadStrategy = extensionLoader.getExtension(\"http\");\n downloadStrategy.download();\n }\n}采用Http下载方式\nProcess finished with exit code 0从获取扩展点的方式我们可以发现，dubbo扩展点是获取具体的实例，并不需要实例化所有的实现类。
\n从示例中我们了解到从ExtensionLoader.getExtensionLoader方法中可以看到类似于工厂方法，获取扩展点的Extension，再通过调用getExtension方法传入指定的名字即可获取到指定的扩展点实现类。
public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {\n if (type == null) {\n throw new IllegalArgumentException(\"Extension type == null\");\n }\n if (!type.isInterface()) {\n throw new IllegalArgumentException(\"Extension type (\" + type + \") is not an interface!\");\n }\n if (!withExtensionAnnotation(type)) {\n throw new IllegalArgumentException(\"Extension type (\" + type +\n \") is not an extension, because it is NOT annotated with @\" + SPI.class.getSimpleName() + \"!\");\n }\n // 查看本地是否存在扩展点类型的Loader\n // 创建一个ExtensionLoader 并且将ExtensionFactory 的实现类均放入这个EXTENSION_LOADERS的本地map缓存中\n // ExtensionFactory 的实现有SpiExtensionFactory 和 SpringExtensionFactory\n ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);\n if (loader == null) {\n EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));\n loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);\n }\n return loader;\n }
getExtension(name)\n -> createExtension(name) #缓存获取 无缓存则创建\n -> getExtensionClasses().get(name) #从缓存中获取name的扩展点类型\n -> 实例化扩展类\n -> injectExtension(instance) # 扩展点IOC注入\n -> instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance)) \n #循环遍历所有wrapper实现，实例化wrapper并进行扩展点IOC注入获取Dubbo的扩展点就从这个方法ExtensionLoader.getExtension(String name)出发吧。
public T getExtension(String name, boolean wrap) {\n if (StringUtils.isEmpty(name)) {\n throw new IllegalArgumentException(\"Extension name == null\");\n }\n //如果传入的name为字符串true 则返回默认的扩展点\n if (\"true\".equals(name)) {\n return getDefaultExtension();\n }\n //从缓存中获取Holder 不存在则创建该缓存对象 并且从缓存中拿，可以防止放入缓存中失败的情况、\n //dubbo 实际将扩展类封装在Holder类中\n final Holder<Object> holder = getOrCreateHolder(name);\n Object instance = holder.get();\n if (instance == null) {\n //double-check 保证线程安全\n synchronized (holder) {\n instance = holder.get();\n if (instance == null) {\n //缓存中没有就创建该扩展点\n instance = createExtension(name, wrap);\n //放入缓存 下次直接从缓存中拿取\n holder.set(instance);\n }\n }\n }\n return (T) instance;\n }在上述getDefaultExtension()方法主要是去拿默认扩展点名称，在load所有扩展点的方法里，会判断@SPI中的value值，即为默认的扩展点名称，将会赋值给cachedDefaultName，所以这里可以拿到一个默认扩展类。
接下来看看createExtension(String name,boolean wrap)方法如何创建扩展点。
private T createExtension(String name, boolean wrap) {\n //name:spi 获取到SpiExtensionFactory\n Class<?> clazz = getExtensionClasses().get(name);\n if (clazz == null || unacceptableExceptions.contains(name)) {\n throw findException(name);\n }\n try {\n //加载本地缓存Map(SpringExtensionFactory. SpiExtensionFactory)中的SpiExtensionFactory\n T instance = (T) EXTENSION_INSTANCES.get(clazz);\n if (instance == null) {\n //name:spi clazz:SpiExtensionFactory 这里反射将其加载到缓存中\n EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.getDeclaredConstructor().newInstance());\n instance = (T) EXTENSION_INSTANCES.get(clazz);\n }\n //IOC注入\n injectExtension(instance);\n\n\n if (wrap) {\n //包装类装饰\n List<Class<?>> wrapperClassesList = new ArrayList<>();\n if (cachedWrapperClasses != null) {\n wrapperClassesList.addAll(cachedWrapperClasses);\n wrapperClassesList.sort(WrapperComparator.COMPARATOR);\n Collections.reverse(wrapperClassesList);\n }\n\n if (CollectionUtils.isNotEmpty(wrapperClassesList)) {\n for (Class<?> wrapperClass : wrapperClassesList) {\n Wrapper wrapper = wrapperClass.getAnnotation(Wrapper.class);\n if (wrapper == null\n || (ArrayUtils.contains(wrapper.matches(), name) && !ArrayUtils.contains(wrapper.mismatches(), name))) {\n instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));\n }\n }\n }\n }\n\n initExtension(instance);\n return instance;\n } catch (Throwable t) {\n throw new IllegalStateException(\"Extension instance (name: \" + name + \", class: \" +\n type + \") couldn't be instantiated: \" + t.getMessage(), t);\n }\n }ExtensionFactory，injectExtension方法可以将扩展点中需要注入的依赖去ExtensionFactory中找到，并且赋值。cachedWrapperClasses变量，不为空则会遍历，并且拿到具体Class对象的构造器，将刚刚反射创建的扩展点包装进来，并且进行Ioc依赖。继续看上面的关键方法getExtensionClasses() 寻找扩展点
private Map<String, Class<?>> getExtensionClasses() {\n //缓存加载\n Map<String, Class<?>> classes = cachedClasses.get();\n if (classes == null) {\n //double-check\n synchronized (cachedClasses) {\n classes = cachedClasses.get();\n if (classes == null) {\n //关键方法:获取所有扩展点 \n classes = loadExtensionClasses();\n cachedClasses.set(classes);\n }\n }\n }\n return classes;\n }根据我们上面的示例，这里在loadExtensionClasses()方法加载完后，classes变量应该有两个值,key-name,value-class的形式存在，分别为：
\"http\" -> {Class@1390} \"class cc.ccoder.loader.HttpDownloadStrategy\"\n\"sftp\" -> {Class@1391} \"class cc.ccoder.loader.SftpDownloadStrategy\"然后继续查看关键方法loadExtensionClasses()
private Map<String, Class<?>> loadExtensionClasses() {\n //获取扩展点上的@SPI注解 并且缓存默认扩展点名称\n cacheDefaultExtensionName();\n\n //所有扩展点放入缓存\n Map<String, Class<?>> extensionClasses = new HashMap<>();\n\n //加载策略 这里是一个工厂方法;对指定文件夹进行加载\n //DubboInternalLoadingStrategy => META-INF/dubbo/internal/\n //DubboLoadingStrategy => META-INF/dubbo/\n //ServicesLoadingStrategy => META-INF/services/\n for (LoadingStrategy strategy : strategies) {\n loadDirectory(extensionClasses, strategy.directory(), type.getName(), strategy.preferExtensionClassLoader(),\n strategy.overridden(), strategy.excludedPackages());\n loadDirectory(extensionClasses, strategy.directory(), type.getName().replace(\"org.apache\", \"com.alibaba\"),\n strategy.preferExtensionClassLoader(), strategy.overridden(), strategy.excludedPackages());\n }\n\n return extensionClasses;\n }之前版本的的加载时直接对这几个文件夹进行loadingDirectory，重新调整后通过工厂方法类，UML如下：
loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY, type.getName());\nloadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY, type.getName().replace(\"org.apache\", \"com.alibaba\"));\nloadDirectory(extensionClasses, DUBBO_DIRECTORY, type.getName());\nloadDirectory(extensionClasses, DUBBO_DIRECTORY, type.getName().replace(\"org.apache\", \"com.alibaba\"));\nloadDirectory(extensionClasses, SERVICES_DIRECTORY, type.getName());\nloadDirectory(extensionClasses, SERVICES_DIRECTORY, type.getName().replace(\"org.apache\", \"com.alibaba\"));![\"image-20210720191055545\"](\"https://tva1.sinaimg.cn/large/008i3skNgy1gsnmkm6ngnj31fo0iuwha.jpg\")
继续主线往下看，接下来就需要看看cachedDefaultExtensionName()方法做了哪些事情
/**\n * extract and cache default extension name if exists\n */\n private void cacheDefaultExtensionName() {\n //拿到@SPI注解\n final SPI defaultAnnotation = type.getAnnotation(SPI.class);\n if (defaultAnnotation == null) {\n return;\n }\n //拿到@SPI注解的value\n String value = defaultAnnotation.value();\n if ((value = value.trim()).length() > 0) {\n String[] names = NAME_SEPARATOR.split(value);\n //从这里可以看到默认扩展点只能够这只一个\n if (names.length > 1) {\n throw new IllegalStateException(\"More than 1 default extension name on extension \" + type.getName()\n + \": \" + Arrays.toString(names));\n }\n if (names.length == 1) {\n //将这个值复制给cachedDefaultName\n cachedDefaultName = names[0];\n }\n }\n }这里加载默认扩展点就和之前的相对应上，默认扩展点的加载时会获取@SPI注解的value,将其赋值给cachedDefaultName变量，在获取默认扩展点时，检查此变量并且从缓存中获取到默认扩展点。
然后继续回到上面loadDirectory方法会这三个路径下的文件进行加载，我们的配置文件以扩展接口全限定名称作为文件名放入以上三个相对路径其中之一即可，即可被loadingDirectory方法加载读取到。
private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir, String type,\n boolean extensionLoaderClassLoaderFirst, boolean overridden, String... excludedPackages) {\n //将相对路径和全限定类名作为文件路径\n //例如: META-INF/services/cc.ccoder.loader.HttpDownloadStrategy\n String fileName = dir + type;\n try {\n Enumeration<java.net.URL> urls = null;\n ClassLoader classLoader = findClassLoader();\n\n // try to load from ExtensionLoader's ClassLoader first\n //首先尝试从ExtensionLoader的类加载器加载 该属性在LoaderStrategy接口中是一个默认方法并且为false\n if (extensionLoaderClassLoaderFirst) {\n ClassLoader extensionLoaderClassLoader = ExtensionLoader.class.getClassLoader();\n if (ClassLoader.getSystemClassLoader() != extensionLoaderClassLoader) {\n urls = extensionLoaderClassLoader.getResources(fileName);\n }\n }\n\n if (urls == null || !urls.hasMoreElements()) {\n if (classLoader != null) {\n //根据文件路径获取文件\n urls = classLoader.getResources(fileName);\n } else {\n urls = ClassLoader.getSystemResources(fileName);\n }\n }\n\n if (urls != null) {\n while (urls.hasMoreElements()) {\n //对文件中内容 进行逐条加载资源\n java.net.URL resourceURL = urls.nextElement();\n loadResource(extensionClasses, classLoader, resourceURL, overridden, excludedPackages);\n }\n }\n } catch (Throwable t) {\n logger.error(\"Exception occurred when loading extension class (interface: \" +\n type + \", description file: \" + fileName + \").\", t);\n }\n }上面loadDirectory方法会依次读取配置文件中扩展点配置，并且执行方法loadResource方法进行加载资源。
private void loadResource(Map<String, Class<?>> extensionClasses, ClassLoader classLoader,\n java.net.URL resourceURL, boolean overridden, String... excludedPackages) {\n try {\n //创建流 准备读取文件中内容\n try (BufferedReader reader = new BufferedReader(new InputStreamReader(resourceURL.openStream(), StandardCharsets.UTF_8))) {\n String line;\n String clazz = null;\n while ((line = reader.readLine()) != null) {\n //定位符# 过滤掉文件中的注释内容\n final int ci = line.indexOf('#');\n if (ci >= 0) {\n line = line.substring(0, ci);\n }\n line = line.trim();\n if (line.length() > 0) {\n try {\n String name = null;\n //定位符 = ,这是正式的记录 并且以=进行分割\n int i = line.indexOf('=');\n if (i > 0) {\n // = 左边的为name\n // = 右边的为class,扩展点的全限定类名\n name = line.substring(0, i).trim();\n clazz = line.substring(i + 1).trim();\n } else {\n // 当然也可以为空 直接整行记录为扩展点的全限定类名\n clazz = line;\n }\n if (StringUtils.isNotEmpty(clazz) && !isExcluded(clazz, excludedPackages)) {\n //加载类，利用反射预加载上面读取到的全限定类名\n loadClass(extensionClasses, resourceURL, Class.forName(clazz, true, classLoader), name, overridden);\n }\n } catch (Throwable t) {\n IllegalStateException e = new IllegalStateException(\n \"Failed to load extension class (interface: \" + type + \", class line: \" + line + \") in \" + resourceURL +\n \", cause: \" + t.getMessage(), t);\n exceptions.put(line, e);\n }\n }\n }\n }\n } catch (Throwable t) {\n logger.error(\"Exception occurred when loading extension class (interface: \" +\n type + \", class file: \" + resourceURL + \") in \" + resourceURL, t);\n }\n }这里就是利用文件流进行读取配置文件，并且过滤注释(#), 逐行读取并且解析分割name和class内容，然后进行loadClass方法加载获取的全限定类名和名称，将其缓存到extensionClasses中。
接下来重点是loadClass这个方法
private void loadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL, Class<?> clazz, String name,\n boolean overridden) throws NoSuchMethodException {\n //扩展类对象必须是扩展点接口的子类\n if (!type.isAssignableFrom(clazz)) {\n throw new IllegalStateException(\"Error occurred when loading extension class (interface: \" +\n type + \", class line: \" + clazz.getName() + \"), class \"\n + clazz.getName() + \" is not subtype of interface.\");\n }\n //自适应扩展点\n if (clazz.isAnnotationPresent(Adaptive.class)) {\n //将cachedWrapperClasses变量设置为clazz\n cacheAdaptiveClass(clazz, overridden);\n } else if (isWrapperClass(clazz)) {\n //判断扩展点构造函数中是否有参数是当前扩展接口类型\n //如果有，则为包装装饰类，将cachedWrapperClasses变量添加到当前clazz\n cacheWrapperClass(clazz);\n } else {\n //此处为普通的扩展点\n //获取默认的构造函数，没有默认构造函数则抛出异常\n clazz.getConstructor();\n if (StringUtils.isEmpty(name)) {\n //如果name为空 则判断类上是否存在@Extension注解，并且该注解的value为name =>extension.value\n //没有此注解则以小写类名为name =>clazz.getSimpleName()\n name = findAnnotationName(clazz);\n if (name.length() == 0) {\n throw new IllegalStateException(\n \"No such extension name for the class \" + clazz.getName() + \" in the config \" + resourceURL);\n }\n }\n\n String[] names = NAME_SEPARATOR.split(name);\n if (ArrayUtils.isNotEmpty(names)) {\n //如果类中有@Activate注解，则将name与注解对象缓存在cacheActivateClass变量中 cachedActivates.put(name, activate)\n cacheActivateClass(clazz, names[0]);\n for (String n : names) {\n //缓存name key:clazz, value:name cachedNames.put(clazz, name);\n cacheName(clazz, n);\n //最后将拿到的扩展类放入map中 extensionClasses.put(name, clazz);\n saveInExtensionClass(extensionClasses, clazz, n, overridden);\n }\n }\n }\n }在saveInExtensionClass方法中如果扩展点作为普通扩展点，则将其放入extensionClasses中，以便后面取用。
/**\n * put clazz in extensionClasses\n */\n private void saveInExtensionClass(Map<String, Class<?>> extensionClasses, Class<?> clazz, String name, boolean overridden) {\n Class<?> c = extensionClasses.get(name);\n if (c == null || overridden) {\n //放入extensionClasses\n extensionClasses.put(name, clazz);\n } else if (c != clazz) {\n // duplicate implementation is unacceptable\n unacceptableExceptions.add(name);\n String duplicateMsg =\n \"Duplicate extension \" + type.getName() + \" name \" + name + \" on \" + c.getName() + \" and \" + clazz.getName();\n logger.error(duplicateMsg);\n throw new IllegalStateException(duplicateMsg);\n }\n }现在我们就可以回忆一下，@SPI扩展点的获取基本完成，并且从loadClass中发现只有普通扩展点才会被放入extensionClasses中。
@Adaptive注解，则将clazz放入cachedAdaptiveClass变量中，表示此类为自适应扩展类cachedWrapperClasses变量，表示此类为包装装饰类extensionClasses中，后续从该Map中获取。一般来说扩展点都是普通扩展点，我们可以从extensionClasses中取用，那么就可以会到createExtension方法中从这个map中使用name拿取clazz对象，利用反射实例化进行使用。Class<?> clazz = getExtensionClasses().get(name);
上面createExtension方法中提到了injectExtension(instance)进行注入。在获得扩展类时并不是简单的返回扩展类对象，而是会调用该方法后再进行返回，并且在包装类中也会调用此方法注入依赖再进行返回。那么就来看看injectExtension(instance)方法都做了哪些事情。
private T injectExtension(T instance) {\n //objectFactory 是ExtensionFactory 的变量，在类构造器根据自适应扩展点进行初始化\n //类似于IOC容器工厂 实现的有SpiExtensionFactory SpringExtensionFactory\n if (objectFactory == null) {\n return instance;\n }\n\n try {\n //反射遍历实例中所有的方法\n for (Method method : instance.getClass().getMethods()) {\n //判断是否为setter方法:\n //方法名以set开头 startWith('set')\n // 方法参数只有一个 getParameterTypes.length()==1\n // 方法为public类型 Modifier.isPublic\n if (!isSetter(method)) {\n continue;\n }\n /**\n * Check {@link DisableInject} to see if we need auto injection for this property\n */\n //判断校验该属性是否需要自动注入\n //打上了@DisableInject注解则不需要注入操作\n if (method.getAnnotation(DisableInject.class) != null) {\n continue;\n }\n //获取该方法参数的clazz\n Class<?> pt = method.getParameterTypes()[0];\n if (ReflectUtils.isPrimitives(pt)) {\n continue;\n }\n\n try {\n //获取方法名中需要注入的属性property\n //例如:方法setVersion 获取属性为version 并且将第四个小写 便是version\n String property = getSetterProperty(method);\n //使用参数的clazz与参数名称去ExtensionFactory 的 IOC容器中拿取扩展点类\n Object object = objectFactory.getExtension(pt, property);\n if (object != null) {\n //调用set方法，完成注入\n method.invoke(instance, object);\n }\n } catch (Exception e) {\n logger.error(\"Failed to inject via method \" + method.getName()\n + \" of interface \" + type.getName() + \": \" + e.getMessage(), e);\n }\n\n }\n } catch (Exception e) {\n logger.error(e.getMessage(), e);\n }\n return instance;\n }上述方法阅读完后可以总结如下：
\n@DisableInject标记，则不需要进行注入ExtensionFactory的IOC容器objectFactory是如何获取到扩展点的，便是下面的自适应扩展机制。从上面loadClass中发现，当我们获取扩展类时，如果有的类是包装类，那么此类并不会放extensionClasses类中被获取，而是放入cachedWrapperClasses中，在返回扩展示例的时候包装其他扩展示例。
\n if (wrap) {\n //包装类装饰\n List<Class<?>> wrapperClassesList = new ArrayList<>();\n if (cachedWrapperClasses != null) {\n wrapperClassesList.addAll(cachedWrapperClasses);\n wrapperClassesList.sort(WrapperComparator.COMPARATOR);\n Collections.reverse(wrapperClassesList);\n }\n //前面提到在loadClass中如果扩展类时包装装饰类,便会将其放入cachedWrapperClasses 那么此处wrapperClassList也不会为空\n if (CollectionUtils.isNotEmpty(wrapperClassesList)) {\n for (Class<?> wrapperClass : wrapperClassesList) {\n Wrapper wrapper = wrapperClass.getAnnotation(Wrapper.class);\n if (wrapper == null\n || (ArrayUtils.contains(wrapper.matches(), name) && !ArrayUtils.contains(wrapper.mismatches(), name))) {\n //在此处进行注入包装\n //同样利用反射创建此包装扩展点的实例，并将普通扩展点作为构造器参数传入包装扩展点进行实例化，此时返回的是包装器扩展点\n //将其理解为装饰器模式 在原有的普通扩展点上进行增强 在RPC服务发布与调用时可以提现\n instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));\n }\n }\n }\n }在上面普通扩展机制中其实已经提到了自适应扩展机制，在ExtensionLoader初始化构造函数时便会有objectFactory对象，此对象就是在IOC依赖注入时会使用到，它便是通过自适应扩展机制获取到的。
private ExtensionLoader(Class<?> type) {\n this.type = type;\n objectFactory =\n (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());\n }这里获取到ExtensionFactory接口的所有扩展点实例，但是使用了getAdaptiveExtension方法，也就是说调用该方法便得到的是一个自适应扩展，并不是一个具体的扩展类。
虽然我们可以获取到具体的扩展点类，但是并不想一开始就获取，而是在运行时动态获取。如果一开始就调用ExtensionLoader.getExtension()获取了扩展点，那么之后便无法去改变它。
通过上述了解明白Dubbo通过一个URL去动态加载扩展点，同时url也是通过配置文件获取。这样我们就可以在配置文件中使用zookeeper作为注册中心，修改配置文件后又可以将redis作为配置中心。dubbo根据配置文件的URL进行驱动，自适应加载不同的注册中心，在源码中出现过很多次，与上面SPI获取指定扩展点相配合坐到灵活扩展、动态配置。
\n@Adaptive作用在类上，dubbo会将类作为自适应扩展类。@Adaptive作用在方法上，dubbo会动态的生成代码逻辑。例如ProxyFactory是一个自适应扩展类，注解作用在方法上时，将动态产生一个类叫做ProxyFactory$Adaptive，其中方法逻辑全部由dubbo生成。ProxyFactory自适应扩展类上也被@SPI注解作用。public T getAdaptiveExtension()\n -> createAdaptiveExtension() #从缓存中获取 否则创建\n -> getAdaptiveExtensionClass().newInstance() #获取AdaptiveExtensionClass\n -> getExtensionClasses() # 加载当前扩展所有实现，看是否有实现被标注为@Adaptive\n -> createAdaptiveExtensionClass() #如果没有实现被标注为@Adaptive，则动态创建一个Adaptive实现类\n -> createAdaptiveExtensionClassCode() #动态生成实现类java代码\n -> compiler.compile(code, classLoader) #动态编译java代码，加载类并实例化\n -> injectExtension(instance)接下来就从ExtensionLoader的构造方法中找到getAdaptiveExtension方法，以该方法为入口看看自适应扩展点。
public T getAdaptiveExtension() {\n //缓存获取\n Object instance = cachedAdaptiveInstance.get();\n if (instance == null) {\n if (createAdaptiveInstanceError != null) {\n throw new IllegalStateException(\"Failed to create adaptive instance: \" +\n createAdaptiveInstanceError.toString(),\n createAdaptiveInstanceError);\n }\n\n //double-check\n synchronized (cachedAdaptiveInstance) {\n instance = cachedAdaptiveInstance.get();\n if (instance == null) {\n try {\n //创建自适应扩展实例\n //这里需要关注createAdaptiveExtension方法\n instance = createAdaptiveExtension();\n cachedAdaptiveInstance.set(instance);\n } catch (Throwable t) {\n createAdaptiveInstanceError = t;\n throw new IllegalStateException(\"Failed to create adaptive instance: \" + t.toString(), t);\n }\n }\n }\n }\n\n return (T) instance;\n }这个方法中和之前的逻辑差不多，缓存获取、double-check、创建扩展点实例。
\n在此我们需要着重关注createAdaptiveExtension方法
private T createAdaptiveExtension() {\n try {\n //getAdaptiveExtensionClass获取到自适应类后进行IOC注入，IOC注入和之前的逻辑一样\n return injectExtension((T) getAdaptiveExtensionClass().newInstance());\n } catch (Exception e) {\n throw new IllegalStateException(\"Can't create adaptive extension \" + type + \", cause: \" + e.getMessage(), e);\n }\n }这里逻辑比较简单，通过getAdaptiveExtensionClass方法获取到自适应类，然后再IOC注入，注入逻辑前面已经提到了。
那么接下里再看看getAdaptiveExtensionClass方法如何获取自适应类。
private Class<?> getAdaptiveExtensionClass() {\n //加载所有扩展点\n getExtensionClasses();\n //如果扩展点上存在@Adaptive注解 则cachedAdaptiveClass缓存变量不为空\n if (cachedAdaptiveClass != null) {\n //存在@Adaptive注解作用在类上 表示该自适应扩展类为人工编码 直接返回\n return cachedAdaptiveClass;\n }\n //表示没有@Adaptive注解标志 那么dubbo将生成自适应扩展类\n return cachedAdaptiveClass = createAdaptiveExtensionClass();\n }在getAdaptiveExtensionClass中开始会使用getExtensionClass加载所有自适应扩展类，然后判断是否存在@Adaptive注解
@Adaptive注解，便会将其赋值给cacheAdaptiveClass对象，表示此自适应扩展类为人工编码，直接返回。下面看看这个类图。
\n![\"image-20210721110640532\"](\"https://tva1.sinaimg.cn/large/008i3skNly1gsoe73lyzxj31nk0n8jun.jpg\")
这里面我们着重看一下AdaptiveExtensionFactory如何自适应创建扩展类。
@Adaptive\npublic class AdaptiveExtensionFactory implements ExtensionFactory {\n\n private final List<ExtensionFactory> factories;\n\n public AdaptiveExtensionFactory() {\n //自定义调整扩展点类的加载\n ExtensionLoader<ExtensionFactory> loader = ExtensionLoader.getExtensionLoader(ExtensionFactory.class);\n List<ExtensionFactory> list = new ArrayList<ExtensionFactory>();\n for (String name : loader.getSupportedExtensions()) {\n //扩展点类加载得到后 直接放入factories中\n list.add(loader.getExtension(name));\n }\n factories = Collections.unmodifiableList(list);\n }\n\n @Override\n public <T> T getExtension(Class<T> type, String name) {\n //由于factories已经获取到了ExtensionFactory的所有扩展点类 这里依次读取即可\n for (ExtensionFactory factory : factories) {\n T extension = factory.getExtension(type, name);\n //获取到type name 这样的扩展点 直接返回\n if (extension != null) {\n return extension;\n }\n }\n return null;\n }\n\n}这里可以看到AdaptiveExtensionFactory使用自定义的方式加载了ExtensionFactory的所有扩展点类，这样只需要在配置文件里面添加一个ExtensionFactory扩展点类，便可以动态的加载IOC容器，多增加一个IOC依赖来源。
同时在上面AdaptiveExtensionFactory类上面存在@Adaptive注解，那么便会直接将其返回，如果并不存在该注解dubbo便会自动创建自适应扩展类。这里继续回到上面createAdaptiveExtension方法的最后一行 createAdaptiveExtensionClass();
private Class<?> createAdaptiveExtensionClass() {\n //创建一个生成类 类型=DownloadStrategy 扩展点类型 ，扩展点接口的class对象 和 默认扩展点名称\n //这里需要看看generate方法是如何生成的\n String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();\n //拿到ExtensionLoader的ClassLoader\n ClassLoader classLoader = findClassLoader();\n //自适应方式拿到编译类 然后将代码进行编译 classLoader进行加载 最终编程一个Class对象\n org.apache.dubbo.common.compiler.Compiler compiler =\n ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();\n return compiler.compile(code, classLoader);\n }ExtensionLoader的ClassLoaderClassLoader加载，最终得到一个Class对象。上面提到了重点是这个generate方法用来生成自适应扩展点类。
public String generate() {\n // no need to generate adaptive class since there's no adaptive method found.g\n //方法上无法找到@Adaptive注解 不需要生成自适应类 因为找不到自适应方法\n if (!hasAdaptiveMethod()) {\n throw new IllegalStateException(\"No adaptive method exist on extension \" + type.getName() + \", refuse to create the adaptive class!\");\n }\n\n StringBuilder code = new StringBuilder();\n //生成包名 package cc.ccoder.loader;\n code.append(generatePackageInfo());\n //导入依赖 import org.apache.dubbo.common.extension.ExtensionLoader;\n code.append(generateImports());\n //这里生成类名 之前说到的添加一个$Adaptive后缀 例如ProxyFactory生成的自适应代码ProxyFactory$Adaptive\n //public class %s$Adaptive implements %s {\n code.append(generateClassDeclaration());\n\n Method[] methods = type.getMethods();\n for (Method method : methods) {\n //依次生成方法\n code.append(generateMethod(method));\n }\n code.append(\"}\");\n\n if (logger.isDebugEnabled()) {\n logger.debug(code.toString());\n }\n //返回代码 此时代码结构已经有了返回即可\n return code.toString();\n }主要是这几个步骤：
\n@Adaptive注解，是否需要生成自适应类package xxxxxxinport org.apache.dubbo.common.extension.ExtensionLoader$Adaptive。public class %s$Adaptive implements %s {generateMethod方法中是如何生成方法 private String generateMethod(Method method) {\n //获取方法的返回值类型\n String methodReturnType = method.getReturnType().getCanonicalName();\n //获取方法的名称\n String methodName = method.getName();\n //获取方法内容\n String methodContent = generateMethodContent(method);\n //获取方法的参数\n String methodArgs = generateMethodArguments(method);\n //获取方法抛出异常\n String methodThrows = generateMethodThrows(method);\n //通过这个模板生成方法\n //\"public %s %s(%s) %s {\\n%s}\\n\";\n return String.format(CODE_METHOD_DECLARATION, methodReturnType, methodName, methodArgs, methodThrows, methodContent);\n }从这个generateMethod我们已经有些眉目了。获取待生成方法的返回值类型，获取方法名称，获取方法内容，获取方法参数以及抛出的异常信息，并且通过public %s %s(%s) %s {\\n%s}\\n这个模板进行生成。那么这里我们只需要着重看一下如何获取方法内容。通过generateMethodContext方法生成方法内容。
private String generateMethodContent(Method method) {\n //首选获取到方法上的@Adaptive注解\n Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class);\n StringBuilder code = new StringBuilder(512);\n if (adaptiveAnnotation == null) {\n //如果此方法上面没有@Adaptive注解 便不为此方法生成动态方法 并且抛出一个异常UnsupportedOperationException\n return generateUnsupported(method);\n } else {\n //获取URL参数索引\n int urlTypeIndex = getUrlTypeIndex(method);\n\n // found parameter in URL type\n //在URL类型中找到参数,如果不为-1表示找到\n if (urlTypeIndex != -1) {\n // Null Point check\n //添加一个arg == null的校验\n code.append(generateUrlNullCheck(urlTypeIndex));\n } else {\n // did not find parameter in URL type\n //没有找到 在其他方法中判断是否可以获取到URL getUrl这个方法\n code.append(generateUrlAssignmentIndirectly(method));\n }\n //获取注解上的value值 代表获取扩展点时get的name值 ，如果不存在则使用类名的值作为键\n String[] value = getMethodAdaptiveValue(adaptiveAnnotation);\n\n //判断参数中是否有Invocation类型的参数，org.apache.dubbo.rpc.Invocation\n boolean hasInvocation = hasInvocationArgument(method);\n \n //生成Invocation参数值的代码 并且进行null校验\n code.append(generateInvocationArgumentNullCheck(method));\n \n //生成从url获取参数的代码 getMethodParameter getParameter getProtocol\n code.append(generateExtNameAssignment(value, hasInvocation));\n // check extName == null?\n //校验extName==null 的代码\n code.append(generateExtNameNullCheck(value));\n \n //生成getExtensionLoader(xxx.class).getExtension(extName)的代码\n code.append(generateExtensionAssignment());\n\n // return statement\n // 生成return语句 扩展点类执行方法\n code.append(generateReturnAndInvocation(method));\n }\n\n return code.toString();\n }上述代码表示生成扩展点类方法内容的方法
\n首先判断方法上是否存在@Adaptive注解，若没有不为此方法生成动态方法，并且抛出以下异常信息，表示该方法不支持动态。
throw new UnsupportedOperationException(\"The method %s of interface %s is not adaptive method!\");生成getUrl方法,动态获取到配置的参数 此时已经校验了参数中是否存在URL
if (arg%d == null) throw new IllegalArgumentException(\"url == null\");\n%s url = arg%d;如果没有便会在其他方法中是否可以获得到url.通过generateUrlAssignmentIndirectly方法判断。
private String generateUrlAssignmentIndirectly(Method method) {\n //获取参数类型\n Class<?>[] pts = method.getParameterTypes();\n\n //遍历所有方法中的参数\n Map<String, Integer> getterReturnUrl = new HashMap<>();\n // find URL getter method\n for (int i = 0; i < pts.length; ++i) {\n for (Method m : pts[i].getMethods()) {\n String name = m.getName();\n //是否已get开头或者参数方法名长度大于3\n //方法名是public的 isPublic\n //方法不是static的 isStatic\n //方法没有参数 getParameterTypes.length == 0\n //方法返回值为URL类型 org.apache.dubbo.common.URL\n if ((name.startsWith(\"get\") || name.length() > 3)\n && Modifier.isPublic(m.getModifiers())\n && !Modifier.isStatic(m.getModifiers())\n && m.getParameterTypes().length == 0\n && m.getReturnType() == URL.class) {\n getterReturnUrl.put(name, i);\n }\n }\n }\n\n if (getterReturnUrl.size() <= 0) {\n // getter method not found, throw\n throw new IllegalStateException(\"Failed to create adaptive class for interface \" + type.getName()\n + \": not found url parameter or url attribute in parameters of method \" + method.getName());\n }\n\n Integer index = getterReturnUrl.get(\"getUrl\");\n if (index != null) {\n //生成获取URL的代码\n return generateGetUrlNullCheck(index, pts[index], \"getUrl\");\n } else {\n Map.Entry<String, Integer> entry = getterReturnUrl.entrySet().iterator().next();\n return generateGetUrlNullCheck(entry.getValue(), pts[entry.getValue()], entry.getKey());\n }\n }那么接下来重点便是这个generateGetUrlNullCheck方法
/**\n * 1, test if argi is null\n * 2, test if argi.getXX() returns null\n * 3, assign url with argi.getXX()\n */\n private String generateGetUrlNullCheck(int index, Class<?> type, String method) {\n // Null point check\n StringBuilder code = new StringBuilder();\n code.append(String.format(\"if (arg%d == null) throw new IllegalArgumentException(\\\"%s argument == null\\\");\\n\",\n index, type.getName()));\n code.append(String.format(\"if (arg%d.%s() == null) throw new IllegalArgumentException(\\\"%s argument %s() == null\\\");\\n\",\n index, method, type.getName(), method));\n\n code.append(String.format(\"%s url = arg%d.%s();\\n\", URL.class.getName(), index, method));\n return code.toString();\n }从上面注释可以看出
\norg.apache.dubbo.common.URL这个类型。也就是说我们最终是从URL获取参数
\n查看是否存在involocation类型，如有则从url中获取involocation.getMethonName参数
没有则从@Apaptive注解获取value值，当存在多个value时,则从value1、value2依次往后取。
//@Adaptive注解value\nString[] value() default {};如果多个value均没有取到后则从@SPI注解中取。
dubbo://10.20.54.65:20886/cc.ccoder.exchange.service.facade.api.ExchangeFacade?前面提到了ProxyFactory会自适应生成扩展点类，下面便是生成的扩展点类。
package org.apache.dubbo.rpc;\n\nimport org.apache.dubbo.common.extension.ExtensionLoader;\n\npublic class ProxyFactory$Adaptive implements org.apache.dubbo.rpc.ProxyFactory {\n public java.lang.Object getProxy(org.apache.dubbo.rpc.Invoker arg0) throws org.apache.dubbo.rpc.RpcException {\n if (arg0 == null) throw new IllegalArgumentException(\"org.apache.dubbo.rpc.Invoker argument == null\");\n if (arg0.getUrl() == null)\n throw new IllegalArgumentException(\"org.apache.dubbo.rpc.Invoker argument getUrl() == null\");\n org.apache.dubbo.common.URL url = arg0.getUrl();\n String extName = url.getParameter(\"proxy\", \"javassist\");\n if (extName == null)\n throw new IllegalStateException(\"Failed to get extension (org.apache.dubbo.rpc.ProxyFactory) name from url (\" + url.toString() + \") use keys([proxy])\");\n org.apache.dubbo.rpc.ProxyFactory extension = ExtensionLoader.getExtensionLoader(org.apache.dubbo.rpc.ProxyFactory.class).getExtension(extName);\n return extension.getProxy(arg0);\n }\n\n public java.lang.Object getProxy(org.apache.dubbo.rpc.Invoker arg0, boolean arg1) throws org.apache.dubbo.rpc.RpcException {\n if (arg0 == null) throw new IllegalArgumentException(\"org.apache.dubbo.rpc.Invoker argument == null\");\n if (arg0.getUrl() == null)\n throw new IllegalArgumentException(\"org.apache.dubbo.rpc.Invoker argument getUrl() == null\");\n org.apache.dubbo.common.URL url = arg0.getUrl();\n String extName = url.getParameter(\"proxy\", \"javassist\");\n if (extName == null)\n throw new IllegalStateException(\"Failed to get extension (org.apache.dubbo.rpc.ProxyFactory) name from url (\" + url.toString() + \") use keys([proxy])\");\n org.apache.dubbo.rpc.ProxyFactory extension = (org.apache.dubbo.rpc.ProxyFactory) ExtensionLoader.getExtensionLoader(org.apache.dubbo.rpc.ProxyFactory.class).getExtension(extName);\n return extension.getProxy(arg0, arg1);\n }\n\n public org.apache.dubbo.rpc.Invoker getInvoker(java.lang.Object arg0, java.lang.Class arg1, org.apache.dubbo.common.URL arg2) throws org.apache.dubbo.rpc.RpcException {\n if (arg2 == null) throw new IllegalArgumentException(\"url == null\");\n org.apache.dubbo.common.URL url = arg2;\n String extName = url.getParameter(\"proxy\", \"javassist\");\n if (extName == null)\n throw new IllegalStateException(\"Failed to get extension (org.apache.dubbo.rpc.ProxyFactory) name from url (\" + url.toString() + \") use keys([proxy])\");\n org.apache.dubbo.rpc.ProxyFactory extension = (org.apache.dubbo.rpc.ProxyFactory) ExtensionLoader.getExtensionLoader(org.apache.dubbo.rpc.ProxyFactory.class).getExtension(extName);\n return extension.getInvoker(arg0, arg1, arg2);\n }\n}ExtensionLoader加载一个具体的扩展点实现类。ExtensionLoader实例AdaptiveExtensionFactory@Adaptive注解是作用在@SPI注解的类上ConcurrentHashSet存储[TOC]
\n\n\n ISO 20022 是一种新兴的全球开放式支付消息传递标准。一种为全球支付数据创建的通用语言和模型，一种提供笔其他标准更高质量的数据，这意味着所有人都能够获得更高质量的付款。一种可以适应新需求和新方法的产品。一个不受单一利益控制的标准。一种可供业内任何人使用并在任何网络上实施的工具。
\n
我们将从ISO20022是什么以及为何可以在各平台机构中流行起来，它的诞生是传递了怎样的一种价值观，或者说解决了哪些行业问题。
\n然后再看看这个标准如何成功传递信息，有哪些机构平台参与了该标准的制作，到目前为止该标准涵盖的行业范围。
\n同时，随着行业发展，有新的内容产生时，如何将这些新兴内容添加到该标准中，这就是该标准的注册流程。后面会提到该标准最终实时落地方案是一个标准xml, ANS存储库。
\n在这里我们可以看到通用、信息标准传递。如果我们可以在所有支付通信中使用单一的消息标准，那么我们就可以节约很多兼容标准不一样所浪费的时间和精力。
\n无论交易对手方是谁？金融机构、金融信息机构商、对私、对公客户都可以使用同一套标准，
\n无论是哪个业务领域？(支付行业、证券行业、贸易服务、发卡行、外汇等)都是可以的，
\n无论是哪个网络？(公网、私网、国内或者国际)都如此。
\n接下来是ISO 20022 的价值体系和解决痛点问题。
\nISO20022旨在实现金融机构及其市场基础设施和最终用户社区之间通信互操性。
\n并且解决许多对于XML金融消息标准重叠化问题。指定所有金融财务标准都是用单一标准化方法，这套标准包括使用方法、指定流程、标准词典存储库等。
\n从这里我们可以看到从本世纪初所流行通信方法。并且都是使用XML方式。
\n有一个问题是：XML并不是一种语言，而是一种元语言。也就是说通过XML标准格式每个人可以定义自己的“方言”。那么这就导致出现了很多种“方言”，并且当多个“方言”专注于同一个领域时，势必会造成资源浪费，重复定义，并且也会进一步增加分歧风险。
\n\n\n\n
\n- MDDL: Market Data Definition Language 市场数据定义语言，是一种基于XML的消息格式，用于交换与金融工具、市场数据相关信息，由SIIA(Software & Information Industry Association 软件信息产业协会 ) 和 FISD(Financial information services division 金融信息服务部) 开发，2000年得到使用，并且获得全行业认可。
\n- FIX: Financial information eXchange 金融信息交换协议 1992年发起的电子通信协议，用于与证券交易、市场相关的国际实时信息交换。
\n- VRXML: Vendor Reporting Extensible Markup Language 供应商报表协议 是一种基于XML 涉及市场数据计费、报表、库存管理等。最初由纽交所开发，目的是使所有部分能够以通用XML格式生成、传输、接收和处理发票和报表。
\n
上述数层间金融行业事业的一些标准协议。
\n为了解决上述的行业“方言”痛点问题，在此ISO给出了建议的解决方案：
\n所有金融标准计划都使用单一标准方法。
\n为了解决这个问题，ISO提出：
\n这便是ISO 20022.
\n如果所有的金融财务标准都是用该套配方，我们将避免重复工作、并且所有的开发通信消息就减少了沟通分歧产生，看起来就像是同一个开发人员开发一样。
\n最终金融行业趋于同一个标准是一个长期目标
\n但是在此期间，和现有标准需要共存，以快速适应市场竞争压力和响应监管要求。
\nISO20022 不仅提供了一种趋于同一标准的长期目标的方法，同时还提供了一种促进多种标准“短期”共存的方法。
\n目前已经存在了很多标准，并且当标准彼此独立开发时，从一种标准到另外一种标准的转换需要将数据直接从一个应用映射到另外一个程序，这是一种高成本、不可扩展、难以维护和试试的方案。
\n每当我们需要支持新的标准时，都会城北的增加复杂性和成本的。
\n\n在此我举个栗子：
\n我们有7个标准，每个标准需要与其他6个标准中的每一个来回通信。我们就需要7*6=42个接口来翻译报文。
\n但是，如果我们增加标准的数量，比如增加3个标准，我们总共有10个标准，每个标准都需要与其他9个标准进行通信。
\n那么此时我们需要10*9=90个翻译接口。
\n对于我们7个标准中的每一个都使用了单个消息模型，只需要将其转化一次到消息模型中，然后从另外的消息模型中进行接收。
\n换句话说，我们只需要为每个标准开发两个翻译接口就行了 （适配器模式）
\n从上面我们可以得知，标准实施可以降低成本，实现适应更快的弹性变化，以便提高整体的性能。
\n这种开发独立于语法的业务模型的方法是ISO20022标准的核心。
\n从长远来看，从模型生成的物理ISO20022消息将成为我们正在寻找的唯一标准，
\n在此之前，多种消息标准模型短期共存，长期趋同。
\n这种图说明业务建模概念
\n\n每个机构都有自己一套内部数据对象来表达各种业务概念。ISO20022的目标是识别和标准化机构之间共享的概念，并将其存储在ISO 20022存储库的数字词典中。
\n在这里使用彼此之间商定的标准，就像乐高积木一样，开发人员可以构建与ISO20022语法无关的消息模型，然后根据所需的语法将其转换成目标消息格式。
\n当前首选的 ISO 20022 语法是 XML 和 ASN.1，但如果选择新的更好的语法，则不需要更改模型：只有将消息模型转换为所需消息格式的规则才会更改。此外，如果针对特定业务领域或特定细分市场使用另一种语法更有效，则使用 ISO 20022 消息模型可确保业务信息从一个消息顺利流向另一个消息，无论使用哪种语法传输该消息商业信息。
\n独立于语法的业务建模是 ISO 20022 标准的关键……
\n模型随着业务的发展而发展，而格式随着技术的发展而发展，以从自动化、易于实施、产品的开放性和廉价性等方面的最新创新中受益。 ISO 20022 配方提供了一种更好、更便宜和更快的方式开发和实施可互操作的消息标准。
\n现在我们看到的是ISO20022的主要内容。详细说一下各项是代表含义：
\n 独立于语法的业务建模方法是该标准最具创新性的特征。
\n 这种建模方法允许开发人员在未来消息的物理格式之前并独立于其捕获“业务标准”。建模方法提出了一种两步法。
\n首先，开发者会描述整体的“业务模型”：谁是参与者，他们完成什么样的流程，他们需要什么样的信息来完成这些流程等。
\n一旦完成，他们将定义最佳的交易流程在正确的时间向正确的参与者传达所需的信息。
\n在接受之前，候选的 ISO 20022 模型由 ISO 提名的行业未来用户代表进行验证。这是为了在 ISO 20022 存储库中发布消息之前获得未来用户的支持。
\nISO 20022 的另一个主要组成部分是它的一组预先商定的设计规则，用于将消息模型转换为所需语法的物理消息格式——目前是 XML 或 ASN.1。这些设计规则确保所有 ISO 20022 XML 或 ASN.1 模式的结构一致，以一种对接收者（和应用程序供应商）“可预测”的方式进行，从而更容易实现自动化。
\n语法设计规则与建模方法明确分离的事实确保了当/如果找到新的更好的语法解决方案时不需要更改模型。
\n此外，该标准的一部分是“逆向工程”技术，用于“重新捕获”现有不符合 ISO 20022 的消息标准的功能，并将其提供给 ISO 20022 模型，从而促进现有消息的互操作性、共存和迁移。他们符合 ISO 20022 的等效标准。
\n正是业务建模和逆向工程的结合使得 ISO 20022 在支持互操作性方面如此独特。
\n上面提到的是ISO20022的价值，在此再说说ISO20022 的另外两个部分，注册过程和仓储库。
\n社区的这种参与可能需要时间，但对于获得良好的标准、将要使用的标准来说绝对是至关重要的。
\n数据字段包含了模型和消息格式。消息格式包含了所有使用的组件，以及包含业务模型、事务和消息的业务流程目录。
\n\n一旦业务理由获得 RMG 批准，并且只要消息尚未获得 SEG 批准，这些消息就称为“候选 ISO 20022 消息”。 一旦获得 SEG 批准发布，这些消息就称为“ISO 20022 消息”或“符合 ISO 20022 的消息”。
\nRMG 注册管理组
\n标准评估组、SEG 和 SubSEG
\n\n\n注册管理组 (RMG- Registration Management Group) 是最高注册机构。它由资深的行业专家组成，他们共同代表了金融行业的各个领域。 RMG 的作用是促进和支持金融服务参与者的参与，以促进高质量的全球相关 ISO 20022 合规商业模式的注册和维护，以交换金融服务的信息。其使命是确保 ISO 20022 是一个值得信赖的标准，为金融服务信息交换提供高质量的商业模式。
\nRMG 监督整个注册过程，包括其他注册机构的表现。如果无法达成共识，或者参与过程的各方之间存在冲突，则它充当“上诉法院”。
\nRMG 评估并优先考虑由希望开发新 ISO 20022 消息的提交组织引入的业务理由。它批准了希望参与 RMG、SEG/SubSEG 和 TSG 的新成员实体的申请。
\nRMG 还发起创建新的标准评估组 (SEG) 和 SubSEG。
\n包括 SUBSEG 在内的标准评估组 (SEG) 是行业专家组，每个专家组代表特定金融领域中 ISO 20022 消息的（未来）用户。他们的作用是确保候选 ISO 20022 消息真正满足未来用户的需求。所有候选 ISO 20022 消息都由一个或多个 SEG 验证，具体取决于消息的范围。 SEG 还批准对现有消息的更改。
\n注册机构 (RA) 是 ISO 20022 财务知识库的守护者。 SWIFT 已被 ISO 提名提供 RA 服务。 RA 的作用是指导提交组织，确保开发的模型符合 ISO 20022 技术规范，并将消息模型转换为兼容的 XML 或 ASN.1 模式。 RA 还负责维护 ISO 20022 网站 并定期发布 ISO 20022 存储库的更新摘录。
\n最后，技术支持组 (TSG) 是一组技术专家，可以帮助任何其他注册机构和提交组织解决与 ISO 20022 配方的使用相关的技术问题。
\n
RMG 包括大量成员实体（国家和组织），表明了社区对 ISO 20022 的兴趣。
\n[TOC]
\n在ISO上下文中，该标准描述了赖以表达信息的协议，而语法是用表达信息的格式或者语言。消息定义提供了对可在各方之间交换的信息和数据格式，包括字段长度、代码、字符集等分类。
\nISO 20022消息可用于完整的端到端支付，包括客户—银行(支付)、银行—银行(支付清算与结算)等，这些金融消息定义分为多个业务领域。同时是由4个业务领域代码来标志。
\n[TOC]
\n ISO 20022《金融服务 金融业通用报文方案》标准是针对金融行业信息交换问题，利用网络及XML技术制订的一个先进的通用报文方案。目前，符合ISO 20022标准的报文规范已在全球范围内得到广泛的应用。ISO对标准的推广使用非常重视，专门组建了ISO 20022标准报文库供全球金融界免费使用，并成立了ISO 20022注册管理机构（RMG）、标准评估机构（SEG）、注册机构（RA）负责该库的维护管理。目前，依据ISO 20022《金融服务 金融业通用报文方案》标准，国际上已开发了4类报文标准，它们是支付（Payment）、外汇与衍生品（FX）、证券（Securities）、贸易服务（Trade Services），共计265项，这些成熟的报文标准均经过ISO 20022注册管理机构的审核批\n准，纳入了ISO 20022库中，成为全球通用的金融业务报文标准。
\n 在我国，ISO 20022标准化开发方法也逐步应用到部分重要金融业信息系统的开发过程。
\n下一步，中国人民银行将以ISO 20022标准的实践应用为契机，逐步建立“中国人民银行系统互联报文库”，建设中国人民银行信息化基础设施，推动信息系统互联互通标准化。
\n ISO 20022标准化开发方法在国内金融业的逐步实施，将为我国金融业信息系统通用报文的开发带来新的理念和活力，为未来信息系统间信息交互与标准统一奠定良好基础。
\n由于目前是做的支付行业项目，涉及到银行出入款项目可能会文件服务器，所以算是一个简单的开场问题。
\nftp和sftp都是日常工作中常用的文件传输方式。
\n需要使用客户端和服务端进行交互。服务端用来存储文件，客户端可以使用FTP协议访问服务端上的资源。
\n默认开放21、20两个端口。21端口用于传输控制类消息，20端口是否使用取决于传输模式：被动模式(Passive)和主动模式(Port)。当然如果使用被动模式，具体使用哪个端口需要客户端和服务端双方协商。
\n主动模式
\n\nFTP客户端和服务器首先通过Port 21端口进行建立连接，通过这个通道发送命令。客户端需要接受数据时在此端口上进行Port命令。Port命令包含了客户端用什么端口进行接受数据，在传输数据时服务器端通过自己的TCP21端口连接到客户端指定的端口进行发送数据。
\n被动模式
\n\n建立通道与主动模式相似，建立之后是Pasv命令。服务器收到呢Pasv命令后随机打开一个高端端口(大于1024)并且通知客户端在这个端口上进行请求，客户端连接FTP服务器此端口，通过三次握手进行建立通道，然后服务器通过这个端口进行数据的传输。
\n注意有防火墙的限制，很多防火墙限制了从外部访问发起的连接，所以防火墙和内网中的FTP很多都是不支持Pasv模式的，因此客户端无法通过防火墙来打开一个高端端口。然后很多内网的客户端无法使用Port模式进行登录FTP服务器，因为从服务器的TCP 20端口无法和内网的客户端建立一个新的连接。
\n然后SFTP是SSH FIle Transfer Protocol，安全的传输协议。同样FTP和SFTP有种相同的语法和功能。SFTP为SSH的其中一部分，是一种传输档案至服务器的安全方式。其实在SSH软件包中，已经包含了一个叫作SFTP的安全文件信息传输子系统，SFTP本身没有单独的守护进程，它必须使用sshd守护进程(端口号默认是22)来完成相应的连接和答复操作，所以从某种意义上来说，SFTP并不像一个服务器程序，而更像是一个客户端程序。
\n对于这个文件，最开始有些懵，所以就简单的介绍了一些FTP的主动、被动模式的工作流程，然后说一下SFTP是一种基于ssh安全认证的加密传输模式。然后说了一下两者在连接方式流程上、安全性上、工作效率上的不同，主要就说了这些内容。
\n然后就开始问到了JUC了，下面就开始了
\n支付业务当中肯定会有线程的操作，那你简单说一下线程的状态是怎样的。
\n四大线程池、七大参数、拒绝策略、工作队列有哪些
\n\n\n\n
\n- MySQL事务隔离级别
\n- 事务及事务隔离级别
\n
脏读（Dirty Read)
\n一个事务读到了另一个未提交事务修改过的数据
\n不可重复读（Non-Repeatable Read)
\n一个事务只能读到另一个已经提交的事务修改过的数据，并且其他事务每对该数据进行一次修改并提交后，该事务都能查询得到最新值。（不可重复读在读未提交和读已提交隔离级别都可能会出现）
\n幻读（Phantom）
\n一个事务先根据某些条件查询出一些记录，之后另一个事务又向表中插入了符合这些条件的记录，原先的事务再次按照该条件查询时，能把另一个事务插入的记录也读出来。（幻读在读未提交、读已提交、可重复读隔离级别都可能会出现）
\n分布式事务顾名思义是分布在不同节点应用上的事务，其实是由多个本地事务组成的，无法满足ACID原则，那么就需要系列解决方案
\n2PC(二阶段提交)
\n3PC
\nTCC(Try-Comfirm-Cancel)
\nTCC是一种尝试性执行,若所有参与结点都有事务执行的条件，那么直接执行事务。否则Cancel回滚操作。
\n本地消息表
\n本地消息表是利用各系统本地事务来实现分布式事务。
\n消息事务
\n消息事务的执行实现方案也是数据最终一致性。
\n最大努力通知
\n对于时间不敏感的业务，短信、邮件通知等。尽最大努力进行推送消息保证事务数据的最终一致性。
\n%开始索引失效\n\n\n
\n- 索引覆盖和索引覆盖
\n
当sql语句select password from table where username = 'cong' 的所求查询字段（select列）和查询条件字段（where子句）全都包含在一个索引(username,password)中，可以直接使用索引查询而不需要回表。这就是覆盖索引，通过使用覆盖索引，可以减少搜索树的次数，是常用的性能优化手段。
联合索引最左原则: 联合索引的多个字段中，只有当查询条件为联合索引的一个字段时，查询才能使用该索引。
\n索引可以用于查询条件字段为索引字段，根据字段值最左若干个字符进行的模糊查询。username like %cong
需要回表查询的全行数据比较少，这就是mysql的索引下推。
\n方面面试官了解目前岗位职能，日常工作(业务+技术点)
\n这里可以引入自己非常熟悉的知识点，引导面试官下一个问题往这上面提问。
\n\n\n\n
\n- 分布式缓存一致性
\n
Cache Aside Pattern（旁路缓存模式)
\n读
\n读Cache,存在直接返回,不存在再从DB中读取并且放回Cache
\n写
\n先更新DB,然后直接删除Cache
\nRead/Write Through Pattern（读写穿透）
\n读
\n读Cache,存在直接返回,不存在再从DB中读取并且放回Cache
\n写
\n读Cache,不存在时直接更新DB。存在时更新Cache,然后进行Cache和DB同步更新。
\nWrite Behind Pattern（异步缓存写入)
\n和读写穿透很相似,都是由Cache负责Cache和DB的读写更新.读写穿透是同步更新Cache和DB,但是异步缓存写入是只更新Cache,不直接更新DB,才用异步批量的方式更新DB。
\n此方式适合一些写入频繁，但是数据一致性要求不高场景。
\n无法保证两次更新均成功,可能存在缓存中为新数据,但DB中仍然是旧数据
\n并发情况下两个线程进行操作可能导致Cache和DB数据不一致问题。
\n\n\n假设请求 A 先操作数据库，请求 B 后操作数据库，但是可能存在请求 B 先写缓存，请求 A 后写缓存的情况，从而导致数据库与缓存之间的数据不一致。
\n
业务如何保证写DB和删除Cache为原子操作,否则会出现写入DB但是Cache未做删除操作，导致数据一致性问题。
\n\n\n\n
\n- 请求1从DB中读取数据A数据
\n- 请求2写操作更新DB中A数据,并且删除Cache中A数据
\n- 请求1将数据A写入Cache
\n
先删Cache,在写入DB之前，若有另外请求读取Cache未命中时,读取DB中‘旧’值将其更新回Cache,此时Cache中为旧值,DB中为新值。
\n\n\n\n
\n- 请求1将Cache中数据A删除
\n- 请求2从Cache中读取A数据时未命中,查询DB并将其回写到Cache中
\n- 请求1继续将DB中A数据更新
\n
这个问题可以引入分布式下单号生成的几种方案。
\n消息队列核心应用场景:削峰、异步和解耦。那么在消息队列中消息模式有推拉模式。
\nPush模式
\nPush模式是服务端根据用户需要，有目的、定时将数据推送到客户端。
\nPull模式
\n客户端主动向服务端获取信息。
\n\n\n有一个文本文件(data.txt)里面每行为一个数字切文件预计有100W行左右,请以最快的速度在一台主机4核cpu/1G内存的主机上找出前100个最大的数字，并且输出其在文件所在行。\n注意：请尽量提供该程序在生产运行所需全部信息。
\n
\n\nLRU(Least recently used 最近最少使用)算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”\n设计一个实现以下接口的LRU缓存方法,不能使用LinkedHashMap.
\n
public interface LruCache<K, V> {\n\n /**\n * Set the capacity of the total cache num\n * \n * @param capacity\n * capacity\n */\n void setCapacity(int capacity);\n\n /**\n * Update cache according to LRU definition. This time complexity of this method should be O(1).\n * \n * @param cacheKey\n * key\n * @param cacheValue\n * value\n */\n void put(K cacheKey, V cacheValue);\n\n /**\n * 获取元素\n * \n * @param cacheKey\n * 元素key\n * @return value\n */\n V get(K cacheKey);\n\n}\n\n\n
\n\n\n
\n\n\n
\n\n\n
\n- 接口幂等性设计实现
\n
\n\n\n
\n- MySQL索引数据结构
\n- MySQL索引类型
\n
\n\n\n
\n\n\n
\n- Redis分布式锁实现
\n
\n\n\n
\n- 线程池工作原理
\n
\n\n\n
\n- Java高并发解决方案
\n
\n\n\n
\n- CAS无锁机制原理
\n
\n\n\n
\n\n\n
\n- hashCode和equal区别
\n
\n\n\n
\n- HashMap 底层实现
\n
\n\n\n
\n- BIO、NIO、AIO总结
\n- IO和NIO区别
\n
\n\n\n
\n- 布隆过滤器原理
\n
\n\n\n
\n\n\n
\n- 热点账户高并发记账方案
\n
\n\n\n
\n- 六种分布式事务解决方案
\n
\n\n\n
\n\n\n
\n\n\n
\n- MySQL日志|事务隔离
\n
\n\n\n
\n- 接口性能优化实践方案
\n
\n\n", "date_published": "2021-12-28T18:18:49.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "面试" ] }, { "title": "欢聚集团(Joyy)—Java海外支付岗位—技术面(一面)总结", "url": "https://blog.ccoder.cc/posts/2021/joyy-ji-shu-mian-one.html", "id": "https://blog.ccoder.cc/posts/2021/joyy-ji-shu-mian-one.html", "summary": "笔试题(牛客网) 给定一个房间连接,准时参加牛客网面试题笔试。 leetcode 144-二叉树的前序遍历 牛客网 求二叉树的前序遍历 首先是简单的自我介绍 面试官会根据简历和自我介绍内容进行提问，找到一个切入口。 首先是提问Java的一些内容。 JVM内存模型知道吗？说一下你对JVM内存模型的理解。 主要有一个图很经典。脑海里面要有这个图。 JVM内...", "content_html": "\n
\n- 限流算法对比、网关限流
\n
给定一个房间连接,准时参加牛客网面试题笔试。
\n面试官会根据简历和自我介绍内容进行提问，找到一个切入口。\n首先是提问Java的一些内容。
\n主要有一个图很经典。脑海里面要有这个图。\n\nclass文件->类加载器(classloader)->加载这个图,哪些内存区间是私有独立的，哪些是线程共享的。
\n主要从类加载流程(加载、验证、解析、初始化)几个过程说一下。\n继续说一下经典的双亲委派模型
\n这几个加载器有一个图很经典脑海里面得有印象。\n还有双亲委派模型的优势是哪些？\n线程上下文加载器是如何对双亲委派模型进行破坏的。
\n这个要说一下HashMap的扩容机制。
\n这个脑海里面也有个线程生命周期的图。New、Runnable、Running、Terminated、Timed_Waiting、Blocked、Waiting等。\n\n在线程转移图中的各个状态是如何跃迁转移的。涉及到哪些方法，在什么时候触发。
\n几个固定的创建方法、七大核心参数、四个拒绝策略这些都是需要提出来的。
\ncorePoolSize maximunPoolSize keepAliveTime unit workQueue threadFactory handlerAbortPolicy DiscardPolicy DiscardOldestPolicy CallerRunsPolicy\n\n\n
\n\n\n
\n- 参考凤凰架构-事务处理
\n- 分布式事务经典七中解决方案
\n
\n\n\n
\n- Java锁Lock的种类
\n
|锁/类型|公平/非公平锁|可重入/不可重入锁|共享/独享锁|乐观/悲观锁|\n|
\n", "date_published": "2021-12-11T18:41:16.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "面试" ] }, { "title": "欢聚集团(Joyy)—Java海外支付岗位—业务技术面(二面+三面)总结", "url": "https://blog.ccoder.cc/posts/2021/joyy-ye-wu-mian-two.html", "id": "https://blog.ccoder.cc/posts/2021/joyy-ye-wu-mian-two.html", "summary": "说说如何实现一个渠道路由系统 路由策略落库方案 可以往规则引擎+Drools进行靠,给出一个合理的解决方案,包括如何快速响应、通用、可动态配置。 渠道评分规则 交易卡组织 对公对私 交易费率(单笔、百分比、交易额度阶梯) 渠道历史成功率/赔付率 渠道结算周期 从上述维度进行系列路由、并且按照一定维度权重进行评分，给出一个最优渠道+部分备用渠道，支付失败...", "content_html": "可以往规则引擎+Drools进行靠,给出一个合理的解决方案,包括如何快速响应、通用、可动态配置。
\n从上述维度进行系列路由、并且按照一定维度权重进行评分，给出一个最优渠道+部分备用渠道，支付失败时进行切换备用渠道，提高整体支付成功率，提升用户体验度。
\n是指支付机构为办理客户委托的支付业务而实际收到的预收待付货币资金。
\n备付金存管银行是指可以为支付机构办理客户备付金的跨行收付业务，并负责对机构存放在所有备付金银行的客户备付金信息进行归集、核对与监管的备付金银行。《非银行支付机构客户备付金存管办法》
\n是指可以为支付机构办理客户备付金的收取和本银行支取业务，并负责对支付机构存放在本银行的客户备付金进行监管的备付金银行。
\n是指支付机构与备付金银行或其授权的一个进内分支机构签订的，约定双方的权利、义务和责任的协议。该协议应当约定支付机构从备付金银行划转客户备付金的支付指令，以及客户备付金发生损失时双方应当承担的偿付责任和相关偿付方式。
\n是指支付机构在备付金银行开立的专户存放客户备付金的活期存款账户，包括备付金存管账户、备付金收付账户和备付金汇缴账户。
\n支付机构在备付金银行开立的，可以以现金形式接收客户备付金、以银行转账方式办理客户备付金收取和支出业务的专用存款账户。支付机构在备付金存管授权行或其辖属机构开立的备付金存管账户称为备付金主存管账户。
\n是支付机构在备付金合作银行开立的，可以以现金形式或以银行转账方式接收客户备付金、以银行资金内部划转方式办理客户备付金支取业务的专用存款账户。支付机构备付金收付账户应该开立在备付金合作授权行。
\n是支付机构在备付金银行开立的可以以现金形式接收或以本银行资金内部划转方式接收客户备付金的专用存款账户。备付金银行应当于每日营业终了前，将备付金汇缴账户内的资金全额划转至支付机构的备付金存管账户或在同一备付金合作银行开立备付金收付账户。支付机构可以通过备付金汇缴账户将客户备付金直接退回至原资金转出账户。
\n是指备付金存管银行的法人机构根据最近90日内支付机构每日日终的客户备付金总量计算的平均值。(非金融机构支付服务管理办法)
\n与商户签有协议或为持卡人提供服务，直接或间接凭交易单据(包括电子单据或纸质单据)参加交换的清算会员单位。
\n是指与收单机构签订银行卡受理协议、按约定受理银行卡并委托收单机构为其完成交易资金结算的企事业单位、个体工商户或其他组织，以及按照国家工商行政管理机关有关规定，开展网络商品交易等经营活动的自然人。
\n指POS终端直接与银联系统相连接，当发生POS消费时，此交易信息先送至银联主机系统，由银联系统自动判断后直接送相关的发卡银行，然后信息再沿路返回。
\n一个基于互联网的商户智能终端,一个帮商户实现智能化,互联网化,大数据化经营的全新POS。拥有融合收款、卡券营销、微商城、消息管理、经营统计分析等多项功能。
\n即一笔交易再终端已经置为成功标志，但是发送到主机的账务交易包没有得到响应，即终端交易超时。所以不确定该笔交易是否在主机端也成功完成吗，为了确保用户的利益，终端重新向主机发送请求，请求取消该笔交易的流水，如果主机端已经交易成功，则回滚交易，否则不处理，然后将处理结果返回给终端。
\n指各商业银行利用自身的结算便利，接收客户的委托代为办理指定款项的收付事宜的业务。
\n用户和商户签订过一些代为扣款的协议后，系统会根据协议按时从客户签订协议的账户中扣除协定的金额，明细备注中就显示为"代扣"。
\n指用户购买商品时，不需开通网银，只需提供银行卡号、户名、手机号等信息，银行验证手机号正确性后，第三方支付机构发送手机动态口令到用户手机上，用户输入正确的手机动态口令，即可完成支付。
\n是银行金融网络系统和互联网网络之间的接口，是由银行操作的将Innernet上传输的数据转换为金融机构内部数据的一组服务器设备，或由指派的第三方处理商家支付信息和顾客的支付指令。
\n是由连连支付为互联网金融行业打造的一款支持实名认证的新型支付产品。相比以往的网络支付方式，认证支付能够确保互联网金融行业的高安全性要求，实现了投资人与持卡人的身份的识别，确保了交易安全。
\n指银行发行的，持卡人按要求交存一定金额的备用金，当备用金账户余额不足支付时，可在规定的信用额度内透支的准贷记卡。
\n也称总分类账。是根据总分类科目开设账户，用来登记全部经济业务，进行总分类核算，提供总括核算资料的分类账簿。总分类账所提供的核算字段里奥，是编制会计报表的主要依据，任何单位都必须设置总分类账。
\n是指将集团公司中所有下属公司指定账户上的资金归集到总公司指定的账户的服务，也称资金清扫。
\n指从审计原始凭证、编制记账凭证开始，通过记账、对账、结账等一系列会计处理，到编制出会计报表的过程。
\n是指利用抵消、合同更新等法律制度，最终取得一方对另一方的一个数额的净债券或净债务，如市场交易者之间，可能互有内容相同，方向相反的多笔交易，在结算或结束交易时，可以将各方债权在相等数额内抵消、仅支付余额。
\n清分是清算的数据准备阶段，主要是将当日的全部网络交易数据按照个成员行之间本带他、他带本、贷记、借记、笔数、金额、轧差净额等进行汇总、整理、分类。结算是指吧某一时期内的所有手指情况进行总结、核算。
\n是清算的数据准备阶段, 主要是将当日的全部网络交易数据按照各成员行之间本代他、他代本、贷记、借记、笔数、金额、轧差净额等进行汇总、整理、分类。是指对交易记录汇总分类并计算出相互结算金额的过程。
\n按明细分类账户登记的账簿叫做明细分类账，简称”明细账“。明细账也称明细分类账，是根据总账科目所属的明细科目设置的，用于分类等级某一类经济业务事项，提供有关明细核算资料。
\n业务发生主体与业务关系方之间的相关利益和支出的划分分账，一般指的是媒体分账合作的一种营销模式。
\n是指同一张银行卡在同一家商户同一终端购买同一商品(或者服务)而发生连续两次(含)以上交易的支付行为。
\n是对前一个清算周期的交易信息进行核对，以确认交易信息的一致性和正确性的过程。
\n确认交易信息一致性和正确性所用到的文件。
\n是指由于机具、通信线路、系统处理、终端操作及其他原因引起，需要进行相应的账务调整的交易。
\n是在数字通信中利用编码方法对传输过程中产生的差错进行管理，以提高数字消息传输的准确性。
\n指的是调取交易签购单及凭证，确认交易真实性。一般由银联、发卡行或收单机构发起，服务商也可以进行发起。
\n由于网络、系统等不确定因素的影响，支付服务方未把支付结果信息返回给下单发起方。
\n在下单成功后，对于未支付的电子支付订单进行撤销的操作。
\n加密运算的结果。
\nPOS终端工作时对工作密钥进行加密的密钥，由银行人员设置并保持在本系统硬件中，只能够使用，不能够读取，该密钥必须与加密算法放在同一加密芯片里。
\n未被加密的信息。
\n预授权指特约商户通过POS或其他方式，就持卡人预支付金额向发卡行索取付款承诺的过程。
\n预授权撤销指特约商户由于各种原因通过POS或其他方式通知发卡行取消付款承诺的过程。
\n预授权完成指持卡人对已取得预授权的交易，在预授权金额或超出预授权金额一定比例的范围内，做支付结算。
\n预授权完成撤销指特约商户由于各种的原因对持卡人已经完成的预授权完成交易，主动发起的预授权完成交易的取消。
\n支付服务提供方用于处理支付指令的系统。
\n付款方通过信用类支付方式付款给收款方后，由于某种原因拒绝支付货款的行为。（黑卡、盗卡、恶意支付等）
\n是指在发生一笔交易时，所缴纳的手续费从这笔金额外收取，区别于内扣。
\n是指在发生一笔交易时，所缴纳的手续费从这笔金额内扣除，区别于外收。
\n指商户应持卡人要求或主动将商品收回或服务取消，通过联机POS 终端等受理机具或者手工方式，将已扣款项通过收单银行退还给持卡人原扣款的过程。
\n针对原交易进行的，将全部或部分支付款项退回到付款方账户的操作。
\n套取现金的简称，一般是指用违法或虚假的手段交换取得现金利益。 多用于信用卡套现、公积金套现、证券套现等。
\n指在交易过程中将款项交付给交易对方。
\n在支付交易中提供资金收、付服务的银行和专业化支付服务提供方。
\n卡的合法持有者，即与卡对应的银行账户相联系的客户。
\n在支付交易中支付资金的一方。
\n在支付交易中接收资金的一方。
\n指跨行交易中兑付现金或与商户签约进行跨行交易资金结算，并且直接或间接地使交易达成转接的银行。
\n与商户签有协议或为持卡人提供服务，直接或间接凭交易单据(包括电子单据或纸质单据)参加交换的清算会员单位。
\n收单非焦点业务包罗但不限于商户拓展与办事、终端布放与维护及生意业务接入等。
\n具有资质的第三方支付机构通过渠道代理方式拓展商户。通俗的讲，就是通过与代理商签约，将POS机使用的商户拓展、资格审查等权力下放。
\n发行银行卡，维护与卡关联的账户，并与持卡人在这两方面具有协议关系的机构。
\n单位、个人直接或授权他人通过电子终端发出支付指令，实现货币支付与资金转移的行为。
\n用户可用以发起电子支付指令的计算机、电话、销售点终端、自动柜员机、移动通讯工具或其他电子设备。
\n支付服务提供方为用户提供的完成电子支付的交易通道，如互联网、WAP、呼叫中心等。
\n实现电子支付的业务处理系统。
\n支付服务提供方对交易记录进行汇总、计算以及资金划转的全过程。
\n基于约定的业务规则，用于电子支付数据交换的规范和技术实现。
\n支付服务提供方在电子支付过程中，对交易行为进行监控。
\n开展电子支付业务过程中，对支付服务提供方的安全策略、内控制度、风险管理、系统安全、用户保护等方面进行的安全测试和管控能力的考察与评价。
\n对电子支付所面临的威胁、存在的弱点、造成的影响以及三者综合作用所带来风险的可能性评估。
\n对前一个结算周期的交易信息进行核对，以确认交易信息的一致性和正确性的过程。
\n包含订单编号、订单金额等支付信息的电子数据。
\n[TOC]
\nhello，大家好，我是聪聪。
\n", "image": "https://ccoder-markdown-oss.oss-cn-shanghai.aliyuncs.com/md/2022-07-16-110323.png", "date_published": "2022-07-28T14:38:57.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "Java" ] }, { "title": "《领域驱动设计》之软件复杂度", "url": "https://blog.ccoder.cc/posts/2022/ddd-software-complexty.html", "id": "https://blog.ccoder.cc/posts/2022/ddd-software-complexty.html", "summary": "hello，大家好，我是聪聪。 最近闲暇时间看了下张逸的《领域驱动设计》，书中对于软件复杂度包含的一些内容，让我有些同感。目前接触的一些系统中都会有一些技术债、坏味道在其中。 那么就在这里结合自身现有的一些系统设计，做一个随笔记录。 1.复杂系统 什么是复杂的系统呢？ 由大量相互作用的部分组成的系统。与整个系统比起来，这些组成部分相对简单，没有中央控制...", "content_html": "hello，大家好，我是聪聪。
\n", "image": "https://ccoder-markdown-oss.oss-cn-shanghai.aliyuncs.com/md/2022-08-09-130840.png", "date_published": "2022-08-08T11:13:36.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "DDD" ] }, { "title": "Go语言基础-数组", "url": "https://blog.ccoder.cc/posts/2022/go-array.html", "id": "https://blog.ccoder.cc/posts/2022/go-array.html", "summary": "hello，大家好，我是聪聪。 1.数组定义 数组是同一类型元素的集合。在go中数组从声明时便已确认，使用时可以修改其成员，但是数组大小不可变化。 [n]T 用来定义数据 n 数组元素个数 T 数组元素的数据类型 var a [10]int 定义一个长度为10，元素类型为int的数组 a 2.数组初始化 2.1 使用初始化列表来完成数组初始化 var ...", "content_html": "hello，大家好，我是聪聪。
\n", "image": "https://ccoder-markdown-oss.oss-cn-shanghai.aliyuncs.com/md/2022-07-28-064228.bmp", "date_published": "2022-09-21T14:10:02.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "Go" ] }, { "title": "viper读取配置文件", "url": "https://blog.ccoder.cc/posts/2022/go-viper.html", "id": "https://blog.ccoder.cc/posts/2022/go-viper.html", "summary": "hello，大家好，我是聪聪。 1. 介绍 Viper是适用于Go应用程序的完整配置解决方案。它被设计用于在应用程序中工作，并且可以处理所有类型的配置需求和格式。它支持以下特性： 设置默认值 从JSON、TOML、YAML、HCL、envfile和Java properties格式的配置文件读取配置信息 实时监控和重新读取配置文件（可选） 从环境变量中...", "content_html": "hello，大家好，我是聪聪。
\n", "image": "https://ccoder-markdown-oss.oss-cn-shanghai.aliyuncs.com/md/2022-09-23-070821.png", "date_published": "2022-09-23T16:29:21.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "Go" ] }, { "title": "货币代码", "url": "https://blog.ccoder.cc/posts/2022/huo-bi-dai-ma.html", "id": "https://blog.ccoder.cc/posts/2022/huo-bi-dai-ma.html", "summary": "ALL 8 阿尔巴尼列克 - Albania Lek 阿尔巴尼 DZD 12 阿尔及利亚第纳尔 - Algerian Dinar 阿尔及利亚 ARS 32 阿根廷比索 - Argentina Peso 阿根廷 AUD 36 澳元 - Australia Dollar 澳大利亚 BSD 44 巴哈马元 - Bahamian Dollar 巴哈马元 BHD...", "content_html": "ALL\t8\t阿尔巴尼列克 - Albania Lek\t阿尔巴尼\nDZD\t12\t阿尔及利亚第纳尔 - Algerian Dinar\t阿尔及利亚\nARS\t32\t阿根廷比索 - Argentina Peso\t阿根廷\nAUD\t36\t澳元 - Australia Dollar\t澳大利亚\nBSD\t44\t巴哈马元 - Bahamian Dollar\t巴哈马元\nBHD\t48\t巴林第纳尔 - Bahrain Dinar\t巴林\nBDT\t50\t孟加拉国塔卡 - Bangladesh Taka\t孟加拉国\nAMD\t51\t亚美尼亚德拉姆 - Armenia Dram\t亚美尼亚\nBBD\t52\t巴巴多斯元 - Barbados Dollar\t巴巴多斯\nBMD\t60\t百慕大元 - Bermudian Dollar\t百慕大\nBTN\t64\t不丹努扎姆 - Bhutanese Ngultrum\t不丹\nBOB\t68\t玻利维亚诺 - Bolivian Boliviano\t玻利维亚\nBWP\t72\t博茨瓦纳普拉 - Botswana Pula\t博茨瓦纳\nBZD\t84\t伯利兹元 - Belize Dollar\t伯利兹\nSBD\t90\t所罗门群岛元 - Solomon Islands Dollar\t所罗门群岛\nBND\t96\t文莱元 - Brunei Dollar\t文莱\nMMK\t104\t缅甸元 - Myanmar Kyat\t缅甸\nBIF\t108\t布隆迪法郎 - Burundi Franc\t布隆迪\nKHR\t116\t柬埔寨瑞尔 - Cambodian Riel\t柬埔寨\nCAD\t124\t加元 - Canadian Dollar\t加拿大\nCVE\t132\t佛得角埃斯库多 - Cape Verde Escudo\t佛得角\nKYD\t136\t开曼群岛元 - Cayman Islands Dollar\t开曼群岛\nLKR\t144\t斯里兰卡卢比 - Sri Lankan Rupee\t斯里兰卡\nCLP\t152\t智利比索 - Chilean Peso\t智利\nCNY\t156\t人民币 - Chinese Yuan\t中国\nCOP\t170\t哥伦比亚比索 - Colombia Peso\t哥伦比亚\nKMF\t174\t科摩罗法郎 - Comorian franc\t科摩罗\nCRC\t188\t哥斯达黎加科朗 - Costa Rica Colon\t哥斯达黎加\nHRK\t191\t克罗地亚库纳 - Croatian Kuna\t克罗地亚\nCUP\t192\t古巴比索 - Cuban Peso\t古巴\nCYP\t196\t塞普路斯镑 - Cyprus Pound\t塞普路斯\nCZK\t203\t捷克克朗 - Czech Republic Koruna\t捷克\nDKK\t208\t丹麦克朗 - Danish Krone\t丹麦\nDOP\t214\t多米尼加比索 - Dominican Peso\t多米尼加\nECS\t218\t厄瓜多尔苏克雷 - Ecuadorian Sucre\t厄瓜多尔\nSVC\t222\t萨尔瓦多科朗 - Salvadoran Colon\t萨尔瓦多\nETB\t230\t埃塞俄比亚比尔 - Ethiopian Birr\t埃塞俄比亚\nERN\t232\t厄立特里亚纳克法 - Eritrean Nakfa\t厄立特里亚\nFKP\t238\t福克兰群岛镑 - Falkland Islands Pound\t福克兰群岛\nFJD\t242\t斐济元 - Fiji Dollar\t斐济\nFRF\t250\t法国法郎 - French Franc\t法国\nDJF\t262\t吉布提法郎 - Djiboutian Franc\t吉布提\nGMD\t270\t冈比亚达拉西 - Gambian Dalasi\t冈比亚\nDEM\t280\t德国马克 - Deutsche Mark\t德国\nGIP\t292\t直布罗陀镑 - Gibraltar Pound\t直布罗陀\nGTQ\t320\t危地马拉格查尔 - Guatemalan Quetzal\t危地马拉\nGNF\t324\t几内亚法郎 - Guinean Franc\t几内亚\nGYD\t328\t圭亚那元 - Guyanese Dollar\t圭亚那\nHTG\t332\t海地古德 - Haitian Gourde\t海地\nHNL\t340\t洪都拉斯伦皮拉 - Honduran Lempira\t洪都拉斯\nHKD\t344\t港币 - Hong Kong Dollar\t香港\nHUF\t348\t匈牙利福林 - Hungarian Forint\t匈牙利\nISK\t352\t冰岛克郎 - Icelandic Krona\t冰岛\nINR\t356\t印度卢比 - Indian Rupee\t印度\nIDR\t360\t印度尼西亚卢比 - Indonesian Rupiah\t印度尼西亚\nIRR\t364\t伊朗里亚尔 - Iranian Rial\t伊朗\nIQD\t368\t伊拉克第纳尔 - Iraqi Dinar\t伊拉克\nIEP\t372\t爱尔兰镑 - Irish Pound\t爱尔兰\nILS\t376\t以色列新谢克尔 - Israeli New Shekel\t以色列\nITL\t380\t意大利里拉 - Italian Lira\t意大利\nJMD\t388\t牙买加元 - Jamaican Dollar\t牙买加\nJPY\t392\t日元 - Japanese Yen\t日本\nKZT\t398\t哈萨克斯坦坚戈 - Kazakstani Tenge\t哈萨克斯坦\nJOD\t400\t约旦第纳尔 - Jordanian Dinar\t约旦\nKES\t404\t肯尼亚先令 - Kenyan Shilling\t肯尼亚\nKPW\t408\t朝鲜元 - North Korean Won\t朝鲜\nKRW\t410\t韩元 - South Korean Won\t韩国\nKWD\t414\t科威特第纳尔 - Kuwaiti Dinar\t科威特\nKGS\t417\t吉尔吉斯斯坦索姆 - Kyrgyzstani Som\t吉尔吉斯斯坦\nLAK\t418\t老挝基普 - Lao kip\t老挝\nLBP\t422\t黎巴嫩镑 - Lebanese Pound\t黎巴嫩\nLSL\t426\t莱索托洛蒂 - Lesotho Loti\t莱索托\nLVL\t428\t拉脱维亚拉特 - Latvian Lats\t拉脱维亚\nLRD\t430\t利比里亚元 - Liberian dollar\t利比里\nLYD\t434\t利比亚第纳尔 - Libyan Dinar\t利比亚\nLTL\t440\t立陶宛立特 - Lithuanian Litas\t立陶宛\nMOP\t446\t澳门元 - Macau Pataca\t澳门\nMWK\t454\t马拉维克瓦查 - Malawian Kwacha\t马拉维\nMYR\t458\t林吉特 - Malaysian Ringgit\t马来西亚\nMVR\t462\t马尔代夫拉菲亚 - Maldives Rufiyaa\t马尔代夫\nMRO\t478\t毛里塔尼亚乌吉亚 - Mauritania Ouguiya\t毛里塔尼亚\nMUR\t480\t毛里求斯卢比 - Mauritian Rupee\t毛里求斯\nMXN\t484\t墨西哥比索 - Mexican Peso\t墨西哥\nMNT\t496\t蒙古图格里克 - Mongolian Tugrik\t蒙古\nMDL\t498\t摩尔多瓦列伊 - Moldovan Leu\t摩尔多瓦\nMAD\t504\t摩洛哥迪拉姆 - Moroccan Dirham\t摩洛哥\nOMR\t512\t阿曼里亚尔 - Omani Rial\t阿曼\nNAD\t516\t纳米比亚元 - Namibian Dollar\t纳米比亚\nNPR\t524\t尼泊尔卢比 - Nepalese Rupee\t尼泊尔\nANG\t532\t荷兰盾 - Dutch Guilder\t荷兰\nAWG\t533\t阿鲁巴弗罗林 - Aruba Florin\t阿鲁巴\nVUV\t548\t瓦努阿图瓦图 - Vanuatu Vatu\t瓦努阿图\nNZD\t554\t新西兰元 - New Zealand Dollar\t新西兰\nNIO\t558\t尼加拉瓜新科多巴 - Nicaraguan Cordoba Oro\t尼加拉瓜\nNGN\t566\t尼日利亚奈拉 - Nigerian Naira\t尼日利亚\nNOK\t578\t挪威克朗 - Norwegian Krone\t挪威\nPKR\t586\t巴基斯坦卢比 - Pakistan Rupee\t巴基斯坦\nPAB\t590\t巴拿马巴波亚 - Panamanian Balboa\t巴拿马\nPGK\t598\t巴布亚新几内亚基那 - Papua New Guinea Kina\t巴布亚新几内亚\nPYG\t600\t巴拉圭瓜拉尼 - Paraguayan Guarani\t巴拉圭\nPEN\t604\t秘鲁新索尔 - Peruvian Nuevo Sol\t秘鲁\nPHP\t608\t菲律宾比索 - Philippine Peso\t菲律宾\nQAR\t634\t卡塔尔里亚尔 - Qatari Riyal\t卡塔尔\nRUB\t643\t俄罗斯卢布 - Russian Ruble\t俄罗斯\nRWF\t646\t卢旺达法郎 - Rwandan Franc\t卢旺达\nSHP\t654\t圣赫勒拿镑 - Saint Helena Pound\t圣赫勒拿(英属)\nSTD\t678\t圣多美多布拉 - Sao Tome Dobra\t圣多美和普林西比\nSAR\t682\t沙特里亚尔 - Saudi Arabian Riyal\t沙特阿拉伯\nSCR\t690\t塞舌尔卢比 - Seychelles Rupee\t塞舌尔\nSLL\t694\t塞拉利昂利昂 - Sierra Leonean Leone\t塞拉利昂\nSGD\t702\t新加坡元 - Singapore Dollar\t新加坡\nVND\t704\t越南盾 - Viet Nam Dong\t越南\nSIT\t705\t斯洛文尼亚托拉尔 - Slovenian Tolar\t斯洛文尼亚\nSOS\t706\t索马里先令 - Somali Shilling\t索马里\nZAR\t710\t南非兰特 - South African Rand\t南非\nZWL\t716\t津巴布韦元 - Zimbabwean Dollar\t津巴布韦\nSZL\t748\t斯威士兰里兰吉尼 - Swazi Lilangeni\t斯威士兰\nSEK\t752\t瑞典克朗 - Swedish Krona\t瑞典\nCHF\t756\t瑞士法郎 - Swiss Franc\t瑞士\nSYP\t760\t叙利亚镑 - Syrian Pound\t叙利亚\nTHB\t764\t泰铢 - Thai Baht\t泰国\nTOP\t776\t汤加潘加 - Tongan Pa'Anga\t汤加\nTTD\t780\t特立尼达多巴哥元 - Trinidad and Tobago Dollar\t特立尼达多巴哥\nAED\t784\t阿联酋迪拉姆 - United Arab Emirates Dirham\t阿联酋\nTND\t788\t突尼斯第纳尔 - Tunisian Dinar\t突尼斯\nUGX\t800\t乌干达先令 - Ugandan Shilling\t乌干达\nMKD\t807\t马其顿代纳尔 - Macedonian Denar\t马其顿\nEGP\t818\t埃及镑 - Egyptian Pound\t埃及\nGBP\t826\t英镑 - British Pound\t英国\nTZS\t834\t坦桑尼亚先令 - Tanzanian Shilling\t坦桑尼亚\nUSD\t840\t美元 - United States Dollar\t美国\nUYU\t858\t乌拉圭比索 - Uruguayan Peso\t乌拉圭\nUZS\t860\t乌兹别克斯坦苏姆 - Uzbekistani Som\t乌兹别克斯坦\nWST\t882\t萨摩亚塔拉 - Samoa Tala\t萨摩亚\nYER\t886\t也门里亚尔 - Yemeni Rial\t也门\nTWD\t901\t新台币 - New Taiwan Dollar\t台湾\nTMT\t934\t土库曼斯坦马纳特 - Turkmenistan Manat\t土库曼斯坦\nGHS\t936\t加纳塞地 - Ghanaian Cedi\t加纳\nVEF\t937\t委内瑞拉玻利瓦尔 - Venezuelan Bolivar Fuerte\t委内瑞拉\nSDG\t938\t苏丹镑 - Sudanese Pound\t苏丹\nRSD\t941\t塞尔维亚第纳尔 - Serbian Dinar\t塞尔维亚\nMZN\t943\t莫桑比克新梅蒂卡尔 - New Mozambican Metical\t莫桑比克\nAZN\t944\t阿塞拜疆马纳特 - Azerbaijan Manat\t阿塞拜疆\nRON\t946\t罗马尼亚列伊 - Romanian Leu\t罗马尼亚\nTRY\t949\t土耳其里拉 - Turkish Lira\t土耳其\nXAF\t950\t中非法郎 - Central African CFA Franc\t中非经济共同体\nXCD\t951\t东加勒比元 - East Caribbean Dollar\t加勒比海(英属)\nXOF\t952\t西非法郎 - West African CFA\t非洲金融共同体\nXPF\t953\t太平洋法郎 - French Pacific Franc\t三个太平洋辖区(法属)\nXAU\t959\t金价盎司 - Ounces of Gold\t贵金属\nXDR\t960\tIMF特别提款权 - IMF Special Drawing Rights\t国际货币基金组织\nXAG\t961\t银价盎司 - Ounces of Silver\t贵金属\nXPT\t962\t珀价盎司 - Ounces of Platinum\t贵金属\nXPD\t964\t钯价盎司 - Ounces of Palladium\t贵金属\nZMW\t967\t赞比亚克瓦查 - Zambian Kwacha\t赞比亚\nSRD\t968\t苏里南元 - Suriname Dollar\t苏里南元\nMGA\t969\t马达加斯加阿里亚里 - Malagasy Ariary\t马达加斯加\nAFN\t971\t阿富汗尼 - Afghan Afghani\t阿富汗\nTJS\t972\t塔吉克斯坦索莫尼 - Tajikistan Somoni\t塔吉克斯坦\nAOA\t973\t安哥拉宽扎 - Angola Kwanza\t安哥拉\nBYR\t974\t白俄罗斯卢布 - Belarusian Ruble\t白俄罗斯\nBGN\t975\t保加利亚列弗 - Bulgaria Lev\t保加利亚\nCDF\t976\t刚果法郎 - Congolese Franc\t刚果\nBAM\t977\t波黑可兑换马克 - Bosnia Convertible Mark\t波黑\nEUR\t978\t欧元 - Euro\t欧盟\nMXV\t979\t墨西哥(资金) - Mexican Unidad De Inversion\t墨西哥\nUAH\t980\t乌克兰格里夫纳 - Ukrainian Hryvnia\t乌克兰\nGEL\t981\t格鲁吉亚拉里 - Georgian Lari\t格鲁吉亚\nPLN\t985\t波兰兹罗提 - Polish Zloty\t波兰\nBRL\t986\t巴西雷亚尔 - Brazilian Real\t巴西\nCLF\t990\t智利比索(基金) - Chilean Unidad de Fomento\t智利\nBTC\t\n比特币 - BitCoin\t中本聪\nCNH\t\n中国离岸人民币 - Chinese Offshore Renminbi\t中国\nXCP\t\n铜价盎司 - Ounces of Copper\t贵金属
\n", "date_published": "2022-02-11T18:24:22.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "清算知识" ] }, { "title": "利用SPI机制进行插件解耦", "url": "https://blog.ccoder.cc/posts/2022/java-spi.html", "id": "https://blog.ccoder.cc/posts/2022/java-spi.html", "summary": "[TOC] hello，大家好，我是聪聪。 最近在重构一款底层数据加解密中间件，里面有一些内容需要解耦： 针对不同数据源处理单独，MySQL、MongoDB、ES数据源进行加解密处理。 可插拔扩展不同加解密算法。 兼容不同日志框架做数据脱敏，自定义客制化脱敏规则。 在这里设想通过SPI机制，让接入业务方可进行插件客制化扩展。 中间件内提供业务通用AES...", "content_html": "[TOC]
\nhello，大家好，我是聪聪。
\n", "image": "https://ccoder-markdown-oss.oss-cn-shanghai.aliyuncs.com/md/2022-08-16-064829.png", "date_published": "2022-08-16T15:07:09.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "Java" ] }, { "title": "京东京喜-武汉-高级Java工程师", "url": "https://blog.ccoder.cc/posts/2022/jd-wuhan-jishumina-one.html", "id": "https://blog.ccoder.cc/posts/2022/jd-wuhan-jishumina-one.html", "summary": "RabbitMQ 多消费者时如何消息分配 RabbitMQ 消息最终一致性解决方案 RabbitMQ 延迟队列、消息延迟推送 RabbitMQ延迟队列 RabbitMQ消费端限流、TTL、死信队列 Redis缓存雪崩、穿透、击穿区别和解决方案 接口调优 接口性能调优方案 Redis和MySQL数据一致性 分布式缓存一致性", "content_html": "\n\n\n
\n\n\n
\n- 接口性能调优方案
\n
\n\n", "date_published": "2022-01-05T14:08:21.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "面试" ] }, { "title": "MySQL-Explain总结", "url": "https://blog.ccoder.cc/posts/2022/mysql-explain.html", "id": "https://blog.ccoder.cc/posts/2022/mysql-explain.html", "summary": "hello，大家好，我是聪聪。 最近在梳理MySQL常用知识点，将已有知识点进行结构化、方便后续回稳固。 今天就来总结梳理一下常用的explain命令。 explian命名是用来获取查询执行计划的信息，查询优化器是如何决定执行查询的主要方法。 1. 如何使用 使用非常简单，只需在查询语句select关键字前添加explain即可。MySQL会在该查询方...", "content_html": "\n
\n- 分布式缓存一致性
\n
hello，大家好，我是聪聪。
\n", "image": "https://ccoder-markdown-oss.oss-cn-shanghai.aliyuncs.com/md/2022-07-28-064228.bmp", "date_published": "2022-08-11T10:40:11.000Z", "date_modified": "2026-07-09T05:08:14.000Z", "authors": [ { "name": "聪聪" } ], "tags": [ "MySQL" ] } ] }