entity

职责 状态码是在http1.0版本加入的，目的是为了在客户端向服务端发送请求的时，描述返回的请求结果，借助状态码浏览器可以知道服务器是否正常处理了请求，还是出现了错误. TODO：GETPOST请求的方法 组成 由三位数字及原因短语组成。如 200 OK。数字中的第一位指定了响应类别，后两位无分类。 响应类别 类别 原因短语 1XX 信息性状态码（Informational) 接收的请求 2XX 成功状态码(Success) 请求正常处理完毕 3XX 重定向状态码（Redirection） 需要进行附加操作已完成请求 4XX 客户端错误状态码（Client Error） 服务器无法处理请求 5XX 服务器错误状态码（Server Error） 服务器处理请求出错 常用HTTP状态码 只要遵守状态码类别定义，即使改变RFC2626中定义的状态码，或者服务端自行创建状态码都没问题，仅记录在RFC2616的状态码就多达40种，再加上webDAV（RFC 2518）和附加HTTP状态码（RFC6585）等扩展，数量则达到60多种。由于过多，我们每个类别只挑出常用的状态码进行说明，全部状态码请参考： https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81/5053660?fr=aladdin RFC（request for

项目中上传图片遇到问题如下 413 Request Entity Too Large 上传图片请求返回 413 Request Entity Too Large 解决方法 经排查，nginx 经过反向代理时候， 是因为请求长度超过了 nginx 默认的最大请求大小，默认 1m 在配置中加入 即可解决 client_max_body_size 5M 总结 一般这种问题排查方向 1、是项目中配置大小做了限制 2、网关做了限制处理 3、服务器端有大小限制 来源： oschina 链接： https://my.oschina.net/hp2017/blog/4500789

【本文版权归微信公众号"代码艺术"（ID：onblog）所有，若是转载请务必保留本段原创声明，违者必究。若是文章有不足之处，欢迎关注微信公众号私信与我进行交流！】 一：唠嗑 鼓捣了两天的Spring Security，踩了不少坑。如果你在学Spring Security，恰好又是使用的Spring Boot，那么给我点个赞吧！这篇博客将会让你了解Spring Security的各种坑！ 阅读前说一下，这篇博客是我一字一字打出来的，转载务必注明出处哦！ 另外，本文已授权微信公众号“后端技术精选”独家发布 二：开始 1.准备 Spring boot 1.5 Mysql 5.7 导入依赖 <!-- Web工程 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 数据库相关 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>mysql<

业务场景 业务场景：首先项目进行分布式拆分之后，按照模块再分为为api层和service层，web层。 其中订单业务的实体类放在com.muses.taoshop.item.entity，而用户相关的实体类放在com.muses.taoshop.user.entity。所以就这样，通过通配符方式去setTypeAliasesPackage ， com.muses.taoshop.*.entity Ant通配符的3中风格： (1) ?：匹配文件名中的一个字符 eg: com/test/entity? 匹配 com/test/entityaa (2) * : 匹配文件名中的任意字符 eg: com/*/entity 匹配 com/test/entity (3) ** ： 匹配文件名中的多重路径 eg: com/**/entity 匹配 com/test/test1/entity mybatis配置类写在common工程，数据库操作有些是可以共用的，不需要每个web工程都进行重复配置。 所以写了个Mybatis配置类： package com.muses.taoshop.common.core.database.config; public class BaseConfig { /** * 设置主数据源名称 */ public static final String DATA

前言 在数据库建设过程中，哪一步最重要？绝大多数资料会告诉你，是需求分析阶段。这一步的好坏甚至直接决定数据库项目的成败。 需求分析阶段，也被称为ER建模(entity-relationship modeling)阶段，也常被称为需求可视化，概念建模等。这一阶段数据库系统开发人员将协同需求方以ER图的方式对业务需求进行可视化展现。 本文将详细介绍(陈氏)ER符号体系，并在其中穿插一些具体实例讲解。 基本概念 1. 实体(entity) 实体表示客观世界中的众多概念，比如：人，地点，事件等。 每个实体本身包含多个实体成员，比如实体人可能包含张三，李四王五等。 在ER图中，实体通常用矩形表示，如下所示： 2. 属性(attribute) 每个实体都有属性，用椭圆表示并用来描述实体各个特征。 比如顾客的特征可能有顾客标识符，顾客姓名，顾客性别，顾客年龄等，如下图所示： 此外，每个实体至少要有一个唯一属性，用下划线标记，如上图中的id字段。 3. 联系(relation) 实体与实体之间通常具有某种关联，在ER图中用菱形表示。比如某职员向某主管汇报，如下图所示： 细心的读者相必发现了，实体间连线的两端，写有一些符号。这些符号被称为基数约束(cardinality constraint)，用来表示实体可以有多少实例与另一实体的实例存在联系。 基数约束共有四种形态： 此为形态一，即强制多个对应

Domain events: design and implementation Domain events versus integration events Semantically, domain and integration events are the same thing: notifications about something that just happened. However, their implementation must be different. Domain events are just messages pushed to a domain event dispatcher , which could be implemented as an in-memory mediator based on an IoC container or any other method. On the other hand, the purpose of integration events is to propagate 传播 committed transactions and updates to additional subsystems , whether they are other microservices, Bounded

一、概述 所谓断点续传，其实只是指下载，也就是要从文件已经下载的地方开始继续下载。在以前版本的HTTP协议是不支持断点的，HTTP/1.1开始就支持了。一般断点下载时才用到Range和Content-Range实体头。HTTP协议本身不支持断点上传，需要自己实现。 二、Range 用于请求头中，指定第一个字节的位置和最后一个字节的位置，一般格式： Range:用于客户端到服务端的请求，可以通过改字段指定下载文件的某一段大小及其单位，字节偏移从0开始。典型格式： Ranges: (unit=first byte pos)-[last byte pos] Ranges: bytes=4000- 下载从第4000字节开始到文件结束部分 Ranges: bytes=0~N 下载第0-N字节范围的内容 Ranges: bytes=M-N 下载第M－N字节范围的内容 Ranges: bytes=-N 下载最后N字节内容 1.以下几点需要注意： (1)这个数据区间是个闭合区间，起始值是0，所以“Range: bytes=0-1”这样一个请求实际上是在请求开头的2个字节。 (2)“Range: bytes=-200”，它不是表示请求文件开始位置的201个字节，而是表示要请求文件结尾处的200个字节。 (3)如果last byte pos小于first byte pos

转自： https://blog.csdn.net/dog250/article/details/105756168 大约10年前，我写过两篇关于Linux内核CFS调度器的文章： https://blog.csdn.net/dog250/article/details/5302865 https://blog.csdn.net/dog250/article/details/5302864 我觉得这两篇文章是垃圾，但我又不删，留着给自己喷吧！ 不就是一个内核参数 kernel.sched_child_runs_first 吗？在今天看来，验证它是否起作用实在太简单了。 首先解释一下 为什么要子进程先运行 。 因为fork的行为造成了后续的COW(copy on write)，一般而言子进程会调用exec而替换掉需要COW的地址空间，子进程先运行可以避免不必要的COW开销。 那么对于CFS调度器而言，kernel.sched_child_runs_first是否有作用呢？我们试一下便知道，依然使用那两篇垃圾文章中的例子： #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h> int main(int argc,char *argv[]) { int v = atoi(argv

1 Kafka Kafka是一个开源分布式的流处理平台，一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。Kafka由Scala和Java编写，2012年成为Apache基金会下顶级项目。 2 Kafka优点 低延迟：Kafka支持低延迟消息传递，速度极快，能达到200w写/秒 高性能：Kafka对于消息的分布，订阅都有高吞吐量。即使存储了TB级的信息，依然能够保证稳定的性能 可靠性：Kafka是分布式，分区，复制和容错的，保证零停机和零数据丢失 可扩展：用户可以从但个代理Broker开始作POC，然后慢慢扩展到由三个Broker组成的小型开发集群，接着扩展到数十个甚至数百个Broker集群进入生产阶段，可以在集群联机时进行扩展，而不会影响整个系统的可用性 多个生产者：无论这些客户使用相同Topic还是多个Topic，Kafka都能无缝处理多个生产者，使得系统可以非常容易聚合来自许多前端系统的数据并使其保持一致 多个消费者：Kafka具有多个消费者设计，可以读取任何但个消息流而不会相互干扰。多个Kafka消费者可以组成一个消费组进行操作并共享消息流，从而确保每一条消息只被整个消费组处理一次 基于磁盘的保留：Kafka使用分布式提交日志，消息能够快速持久化到磁盘上。消息持久化意味着如果消费者落后

Spring Security是Spring提供的一个安全框架，提供认证和授权功能，最主要的是它提供了简单的使用方式，同时又有很高的灵活性，简单，灵活，强大。 我个人博客系统采用的权限框架就是Spring Security，正好整合到SpringCloud里面。 一般系统里关于角色方面通常有这么几张表，角色表、用户-角色表、菜单表、角色-菜单表等。 不过我个人博客系统主要以wordpress作为参考，沿用其12张表,如图: 一、导入Maven依赖 <properties> <jjwt.version> 0.9 . 0 </jjwt.version> <spring-security-jwt.version> 1.0 . 9 .RELEASE</spring-security-jwt.version> </properties> <!-- springsecurity--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring