Exemple de Spring implémentant la séparation lecture-écriture de base de données

La plupart des systèmes de commerce électronique à grande échelle actuels utilisent une technologie de séparation lecture-écriture au niveau de la base de données, qui est une base de données principale et plusieurs bases de données esclaves. La bibliothèque principale est responsable de la mise à jour des données et de l'interrogation des données en temps réel, et la bibliothèque esclave est bien entendu responsable de l'interrogation des données en temps différé. Parce que dans les applications réelles, la base de données lit plus et écrit moins (la fréquence de lecture des données est élevée et la fréquence de mise à jour des données est relativement faible), et la lecture des données prend généralement beaucoup de temps et consomme beaucoup de CPU du serveur de base de données. , affectant donc l'expérience utilisateur. Notre approche habituelle consiste à extraire la requête de la base de données principale, à utiliser plusieurs bases de données esclaves et à utiliser l'équilibrage de charge pour réduire la pression des requêtes sur chaque base de données esclave.

L'objectif de l'utilisation de la technologie de séparation lecture-écriture : réduire efficacement la pression sur la bibliothèque maître et distribuer les demandes des utilisateurs pour l'interrogation de données aux différentes bibliothèques esclaves, garantissant ainsi la robustesse du système. Examinons le contexte de l'adoption de la séparation lecture-écriture.

À mesure que l'activité du site Web continue de se développer, que les données continuent d'augmenter et qu'il y a de plus en plus d'utilisateurs, la pression sur la base de données augmente fondamentalement. pas suffisant. Lorsque cela est nécessaire, la stratégie de séparation de la lecture et de l’écriture peut être utilisée pour modifier le statu quo.

Plus précisément dans le développement, comment parvenir facilement à la séparation de la lecture et de l'écriture ? Il existe actuellement deux méthodes couramment utilisées :

1 La première méthode est notre méthode la plus couramment utilisée, qui consiste à définir 2 Connexion à la base de données, l'une est MasterDataSource et l'autre est SlaveDataSource. Lors de la mise à jour des données, nous lisons le MasterDataSource et lors de l'interrogation des données, nous lisons le SlaveDataSource. Cette méthode est très simple, je n’entrerai donc pas dans les détails.

2 La deuxième méthode de changement dynamique de source de données consiste à intégrer dynamiquement la source de données dans le programme lorsque le programme est en cours d'exécution, choisissant ainsi de lire à partir de la bibliothèque principale ou de la bibliothèque esclave. Les principales technologies utilisées sont : l'annotation, Spring AOP, la réflexion. La méthode de mise en œuvre sera présentée en détail ci-dessous.

Avant d'introduire la méthode d'implémentation, nous préparons d'abord quelques connaissances nécessaires. La classe AbstractRoutingDataSource de Spring

La classe AbstractRoutingDataSource a été ajoutée après Spring 2.0. Examinons d'abord la définition de AbstractRoutingDataSource :

public abstract class AbstractRoutingDataSource extends AbstractDataSource implements InitializingBean {}

AbstractRoutingDataSource hérite de AbstractDataSource, qui est une sous-classe de DataSource. DataSource est l'interface de source de données de javax.sql, définie comme suit :

public interface DataSource extends CommonDataSource,Wrapper {
 
 /**
  * <p>Attempts to establish a connection with the data source that
  * this <code>DataSource</code> object represents.
  *
  * @return a connection to the data source
  * @exception SQLException if a database access error occurs
  */
 Connection getConnection() throws SQLException;
 
 /**
  * <p>Attempts to establish a connection with the data source that
  * this <code>DataSource</code> object represents.
  *
  * @param username the database user on whose behalf the connection is
  * being made
  * @param password the user&#39;s password
  * @return a connection to the data source
  * @exception SQLException if a database access error occurs
  * @since 1.4
  */
 Connection getConnection(String username, String password)
  throws SQLException;
 
}

L'interface DataSource définit 2 méthodes, qui obtiennent toutes deux des connexions à la base de données. Voyons comment AbstractRoutingDataSource implémente l'interface DataSource :

public Connection getConnection() throws SQLException {
    return determineTargetDataSource().getConnection();
  }
 
  public Connection getConnection(String username, String password) throws SQLException {
    return determineTargetDataSource().getConnection(username, password);
  }

Évidemment, il appelle sa propre méthode détermineTargetDataSource() pour obtenir la connexion. La méthode détermineTargetDataSource est définie comme suit :

protected DataSource determineTargetDataSource() {
    Assert.notNull(this.resolvedDataSources, "DataSource router not initialized");
    Object lookupKey = determineCurrentLookupKey();
    DataSource dataSource = this.resolvedDataSources.get(lookupKey);
    if (dataSource == null && (this.lenientFallback || lookupKey == null)) {
      dataSource = this.resolvedDefaultDataSource;
    }
    if (dataSource == null) {
      throw new IllegalStateException("Cannot determine target DataSource for lookup key [" + lookupKey + "]");
    }
    return dataSource;
  }

Ce qui nous préoccupe le plus, ce sont les 2 phrases suivantes :

Object lookupKey = determineCurrentLookupKey();
DataSource dataSource = this.resolvedDataSources.get(lookupKey);

La méthode détermineCurrentLookupKey renvoie la lookupKey et la méthodesolvingDataSources obtient la source de données de la carte en fonction de la lookupKey. RésoluDataSources et déterminéCurrentLookupKey sont définis comme suit :

private Map<Object, DataSource> resolvedDataSources;
 
protected abstract Object determineCurrentLookupKey()

En voyant la définition ci-dessus, avons-nous quelques idées résoluesDataSources est un type de carte. Nous pouvons mettre MasterDataSource. et SlaveDataSource Enregistrez-le sur la carte comme suit :

Nous écrivons une classe DynamicDataSource qui hérite de AbstractRoutingDataSource et implémente sa méthode détermineCurrentLookupKey(), qui renvoie la clé Map, master ou esclave.

D'accord, je m'ennuie un peu après avoir tant parlé. Voyons comment le mettre en œuvre.

La technologie que nous souhaitons utiliser a été mentionnée ci-dessus. Regardons d'abord la définition de l'annotation :

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface DataSource {
  String value();
}

Nous avons également besoin. pour implémenter spring La classe abstraite AbstractRoutingDataSource implémente la méthode détermineCurrentLookupKey :

public class DynamicDataSource extends AbstractRoutingDataSource {
 
  @Override
  protected Object determineCurrentLookupKey() {
    // TODO Auto-generated method stub
    return DynamicDataSourceHolder.getDataSouce();
  }
 
}
 
 
public class DynamicDataSourceHolder {
  public static final ThreadLocal<String> holder = new ThreadLocal<String>();
 
  public static void putDataSource(String name) {
    holder.set(name);
  }
 
  public static String getDataSouce() {
    return holder.get();
  }
}

À partir de la définition de DynamicDataSource, elle renvoie la valeur DynamicDataSourceHolder.getDataSouce() We. La méthode DynamicDataSourceHolder.putDataSource() doit être appelée lorsque le programme est en cours d'exécution pour lui attribuer une valeur. Ce qui suit est la partie centrale de notre implémentation, qui est la partie AOP définie comme suit :

public class DataSourceAspect {
 
  public void before(JoinPoint point)
  {
    Object target = point.getTarget();
    String method = point.getSignature().getName();
 
    Class<?>[] classz = target.getClass().getInterfaces();
 
    Class<?>[] parameterTypes = ((MethodSignature) point.getSignature())
        .getMethod().getParameterTypes();
    try {
      Method m = classz[0].getMethod(method, parameterTypes);
      if (m != null && m.isAnnotationPresent(DataSource.class)) {
        DataSource data = m
            .getAnnotation(DataSource.class);
        DynamicDataSourceHolder.putDataSource(data.value());
        System.out.println(data.value());
      }
       
    } catch (Exception e) {
      // TODO: handle exception
    }
  }
}

Afin de faciliter les tests, je défini 2 bases de données, shop simule la bibliothèque principale et test simule la bibliothèque esclave. La structure des tables de shop et test est la même, mais la configuration de la base de données est la suivante :

<bean id="masterdataSource"
    class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url" value="jdbc:mysql://127.0.0.1:3306/shop" />
    <property name="username" value="root" />
    <property name="password" value="yangyanping0615" />
  </bean>
 
  <bean id="slavedataSource"
    class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url" value="jdbc:mysql://127.0.0.1:3306/test" />
    <property name="username" value="root" />
    <property name="password" value="yangyanping0615" />
  </bean>
   
    <beans:bean id="dataSource" class="com.air.shop.common.db.DynamicDataSource">
    <property name="targetDataSources">
       <map key-type="java.lang.String">
         <!-- write -->
         <entry key="master" value-ref="masterdataSource"/>
         <!-- read -->
         <entry key="slave" value-ref="slavedataSource"/>
       </map>
        
    </property>
    <property name="defaultTargetDataSource" ref="masterdataSource"/>
  </beans:bean>
 
  <bean id="transactionManager"
    class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource" />
  </bean>
 
 
  <!-- 配置SqlSessionFactoryBean -->
  <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
    <property name="dataSource" ref="dataSource" />
    <property name="configLocation" value="classpath:config/mybatis-config.xml" />
  </bean>

.

Configuration au printemps Ajoutez la configuration aop dans

<!-- 配置数据库注解aop -->
  <aop:aspectj-autoproxy></aop:aspectj-autoproxy>
  <beans:bean id="manyDataSourceAspect" class="com.air.shop.proxy.DataSourceAspect" />
  <aop:config>
    <aop:aspect id="c" ref="manyDataSourceAspect">
      <aop:pointcut id="tx" expression="execution(* com.air.shop.mapper.*.*(..))"/>
      <aop:before pointcut-ref="tx" method="before"/>
    </aop:aspect>
  </aop:config>
  <!-- 配置数据库注解aop -->

Ce qui suit est la définition du UserMapper To de MyBatis. facilite les tests, la connexion lit la bibliothèque principale et la liste des utilisateurs lit la bibliothèque esclave :

public interface UserMapper {
  @DataSource("master")
  public void add(User user);
 
  @DataSource("master")
  public void update(User user);
 
  @DataSource("master")
  public void delete(int id);
 
  @DataSource("slave")
  public User loadbyid(int id);
 
  @DataSource("master")
  public User loadbyname(String name);
   
  @DataSource("slave")
  public List<User> list();
}　

D'accord, exécutez notre Eclipse pour voir l'effet, entrez le nom d'utilisateur admin et connectez-vous pour voir l'effet

Ce qui précède représente l'intégralité du contenu de cet article. J'espère qu'il sera utile à l'apprentissage de chacun. J'espère également que tout le monde soutiendra le site Web PHP chinois.

Pour plus d'articles connexes sur des exemples d'implémentation de la séparation lecture-écriture de base de données par Spring, veuillez faire attention au site Web PHP chinois !