乐优商城项目总结day(19)

乐优商城项目总结day(19)

订单----减库存

在创建订单时涉及到了库存的修改，在高并发的情况下减库存应该加锁。考虑到到分布式的问题，jvm自带的锁只能锁住本机，因此此处使用mysql自带的事务与行锁解决。

dao层如下：

@Repository
public interface StockDao extends BaseMapper<Stock> {

    @Update("UPDATE tb_stock SET stock = stock - #{num} WHERE sku_id = #{id} AND stock >= #{num}")
    int decreaseStock(@Param("id") Long id, @Param("num") Integer num);
}

我的理解是：在减库存中，A用户进行了减库存的操作，那么在这个A事务内会对该id的商品加上行锁，在A事务提交之前，
假设此时B用户也同时对该id的商品进行了减库存的操作，那么在B事务里对该id商品的更新是会被阻塞住的，直到A事务成功提交后才会释放行锁，B事务才能继续对该商品的库存进行修改。
后面的stock>=num条件主要是为了保证此次库存修改之后库存数必须大于等于0，否则库存数不足。

有的人会疑惑 update 会导致行锁，如果程序挂了，事务没有提交，其他事务岂不是会一直堵塞在那里，阻碍别的update语句。 经过测试程序挂了，mysql会自己自动放弃锁，使别的update语句顺利执行。

查阅了网上很多资料，说这里用到了乐观锁，但是我搞半天也没看出来。。。。希望大神能指点下。。

行锁升级表锁：
避免行锁升级为表锁，影响并发性能，以下为常见的情况：

• 当update或delete时如果where条件中的字段没有索引，会导致无法使用行锁，行锁会升级为表锁。
• SQL语句赋值与表列类型不匹配时，MySql的优化器会强制转化为匹配的类型，导致行锁升级为表锁，这种情况只发生在原数据类型是string的情况下。

悲观锁与乐观锁

悲观锁(Pessimistic Lock)

顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

上面实现的减库存应该也是基于悲观锁的。

乐观锁(Optimistic Lock)

顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

具体实现可参考：文章1 文章2

对比

两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。

mybatis注解用法

在分页查询订单时，因为查询的条件是动态的，并且涉及到了多表查询，因此单独使用@Select注解以及@Results注解或者selectByExample()都不能解决既要多表查询又要动态查询的要求。因此可以使用xml配置文件的方式或者用@SelectProvider注解以及@Results注解来解决，本项目使用第二种方式。

@SelectProvider是用来动态生成sql的，其用法如下：

type参数为动态生成sql类的class对象，method参数为具体生成哪条动态sql对应的方法名称，在这个类的方法中根据条件生成具体的sql。

@Results是在单表或多表查询之后对结果的映射，可以进行一对一、一对多的映射，类似于xml文件中<resultMap>的作用。

id参数和xml中<resultMap>的id作用差不多，给该映射加上id便于后面的复用。
Result[]参数为一个数组，里面需要传入多个@Result。

每个@Result实际上对应着数据库查询结果的列与实体类字段的映射，如果字段的值不是直接映射，那么需要使用one或者many来进行进一步的查询映射，one为一对一时的映射，many为一对多时的映射。

在select参数中传入对应包下的查询方法，通过@Result中的column传入该方法所需要的参数值,返回的结果将会赋给对应的property。

综合示例如下：

@Repository
public interface OrderDao extends BaseMapper<Order> {

    @SelectProvider(type = OrderProvider.class, method = "queryOrderByPage")
    @Results({
        @Result(column = "order_id", property = "orderId", id = true),
        @Result(column = "order_id", property = "orderStatus", javaType = OrderStatus.class,
        one = @One(select = "com.leyou.order.dao.OrderStatusDao.selectByPrimaryKey")),
        @Result(column = "order_id", property = "orderDetails", javaType = List.class,
        many = @Many(select = "com.leyou.order.dao.OrderDetailDao.queryByOrderId"))
    })
    List<Order> queryOrderByPage(@Param("orderStatus") Integer orderStatus, @Param("userId") Long userId);
}

@Repository
public interface OrderDetailDao extends BaseMapper<OrderDetail> {

    @Select("SELECT * FROM tb_order_detail WHERE order_id = #{orderId}")
    List<OrderDetail> queryByOrderId(@Param("orderId") Long orderId);
}

public class OrderProvider {

    public String queryOrderByPage(Map<String, Object> params) {
        Integer orderStatus = (Integer) params.get("orderStatus");
        SQL sql = new SQL();
        sql.SELECT("o.*").FROM("tb_order o")
                .INNER_JOIN("tb_order_status s ON o.order_id = s.order_id")
                .WHERE("o.user_id = #{userId}");
        if(orderStatus != null) {
            sql.WHERE("s.status = #{orderStatus}");
        }
        sql.ORDER_BY("create_time DESC");
        return sql.toString();
    }
}

注意：如果不是使用通用mapper，而是使用原生的mybatis进行字段映射，一定要注意下划线字段与驼峰字段之间的转换，
可以加上如下配置：

mybatis:
	configuration:
    	map-underscore-to-camel-case: true # 如果不使用通用mapper而是使用mybatis,必须加上,否则返回的下划线字段不会转为驼峰