【万字长文】前端储存方案不完全指北

最新推荐文章于 2024-03-11 18:23:56 发布
最新推荐文章于 2024-03-11 18:23:56 发布
阅读量385 收藏
点赞数
文章标签： 前端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_48176238/article/details/132317080
版权

前言

前端的储存方案有很多，在不同的业务场景下大家会选择不同的储存方案，虽然我们大多数用的是前端储存三剑客(Cookie、LocalStorage、SessionStorage)或者在大型框架中会选择一些全局状态管理方案来储存如：Pinia、Redux等等，但是在某些情况下这些储存方案并不能够完全覆盖需求，所以本文旨在介绍目前前端存在的储存解决方案，。

前端基本储存方案介绍及其优劣

1. Cookies

HTTP Cookie(也叫 Web Cookie 或浏览器 Cookie)是服务器发送到用户浏览器并保存在本地的一小块数据。浏览器会存储 cookie 并在下次向同一服务器再发起请求时携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器——如保持用户的登录状态。Cookie 的出现使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

用途：

Cookie主要用于： 1. 会话状态管理(登录态、购物车、Rank分等) 1. 个性化设置 1. 浏览器行为跟踪

在上古时期的前端，Cookie曾一度被适用于客户端数据的储存，这是因为当时没有其他合适且有些的储存方法而被迫作为的唯一储存手段。但是在现在我们更加推荐去使用现代储存API(下文介绍的其他方式)来进行客户端数据的储存。

优劣：

  • 优势：
    • 简单易用，浏览器支持广泛。
    • 可设置过期时间，可以在客户端存储少量数据。
    • 可通过设置 HttpOnly 属性保护敏感数据。
  • 劣势：
    • 存储容量较小(通常为 4KB)，不适合存储大量数据。
    • 每次请求都会自动发送到服务器，可能影响性能。
    • 存储在客户端，可能被用户篡改。

2. Storage

作为 Web Storage API 的接口，Storage 提供了访问特定域名下的会话存储或本地存储的功能，例如，可以添加、修改或删除存储的数据项。

如果你想要操作一个域名的会话存储，可以使用 Window.sessionStorage；如果想要操作一个域名的本地存储，可以使用 Window.localStorage。它俩一个妈生的，大同小异，根据自己想要的生命周期进行区分即可。

他们对数据操作是同步的。

2.1 LocalStorage

  • 优势：
    • 大碗好用，可以存储较大量的数据(通常为 5-10MB会随着浏览器不同有所差异)。
    • 数据在页面刷新后仍然保持。
    • 不会随着请求自动发送到服务器。
  • 劣势：
    • 存储在客户端，可能被用户篡改。
    • 存储量虽然比 Cookies 大，但仍有限制。

2.2 SessionStorage

  • 优势：
    • 与 localStorage 类似，但仅在当前会话窗口中有效，关闭窗口后数据清除。
  • 劣势：
    • 存储量有限，与 localStorage 类似。

2.3 LocalStorage和SessionStorage的区别汇总

  • 【生命周期】理论上LocalStorage为永久，SessionStorage在本标签页被关闭后即结束
  • 【作用域】LocalStorage在同源的所有窗口和标签页共享，SessionStorage仅在本窗口或标签页中共享
  • 【储存容量】通常情况下，localStorage 的存储容量比 sessionStorage 更大，但具体大小限制因浏览器而异。
  • 【数据访问方式】分属不同API

3. IndexedDB

IndexedDB 是一种底层 API，用于在客户端存储大量的结构化数据(也包括文件/二进制大型对象(blobs))。该 API 使用索引实现对数据的高性能搜索。虽然 Storage在存储较少量的数据很有用，但对于存储更大量的结构化数据来说力不从心。

特点

  • 异步操作: 所有操作都是异步的，不会阻塞主线程，适用于处理大量数据。
  • 事务支持: 支持事务机制，可以确保数据的完整性和一致性。 【这意味着一系列操作步骤之中，只要有一步失败了那么整个事务都会取消，数据库将回滚到事务未发生之前的状态，不会出现只有一部分数据被改变的情况】
  • 索引查询: 可以创建多个索引，以支持灵活的数据查询和排序。
  • 支持二进制数据: 可以存储二进制数据，如图片、视频等。
  • 跨标签访问: 不同浏览器标签页之间可以共享 IndexedDB 数据。
  • 适用于大量数据: 适合存储大量数据，如离线应用、本地缓存等。

使用场景

一个技术如果没有使用场景，那就没用，但是有些同学可能一下子无法想到indexedDB的使用场景这边给大家列举以下场景。

  1. 笔记软件：如我常用的Notion这种类型的软件可能会使用到indexedDB这项技术，当用户没有网络时离线储存数据，并且当有网络时再将离线储存的数据上传至服务器。
  2. TODOList或便签软件：与笔记软件类似
  3. 网站上的富文本编辑器：数据量大，且需要返回上一步，草稿等功能。这类功能讲数据放在服务端会出现各种问题是不现实的，所以就需要接入客户端数据库来解决。
  4. 股票金融类的统计图数据：这些数据都需要实时展示且过去数据基本不会改变，可以把已加载过的数据缓存在客户端来减少服务端的压力。
  5. 缓存最近联系人以及聊天记录
  6. WebGL、3D模型资源：Storage的储存量不够
  7. 电子书
  8. 低代码编辑器(需要拖拉拽，返回上一步等)
  9. 前端封装的桌面应用或APP应用
  10. 有一些大公司用相同的一级域名，储存很容易满的情况下。
  11. 游戏
  12. 面试的时候面试官可能会问
  13. …

储存大小

不同的浏览器厂商对于indexedDB的大小设置各不相同。

并且浏览器的最大存储空间是动态的——它取决于硬盘大小。全局限制为可用磁盘空间的 50％。在 Firefox 中，有一个名为 Quota Manager 的内部浏览器工具会跟踪每个源用尽的磁盘空间，并在必要时删除数据。

因此，如果硬盘驱动器是 500GB，那么浏览器的总存储容量为 250GB。如果超过此范围，则会发起称为源回收的过程，删除整个源的数据，直到存储量再次低于限制。删除源数据没有只删一部分的说法——因为这样可能会导致不一致的问题。

优劣：

  • 优势：
    • 可以存储大量结构化数据，容量较大。
    • 提供异步 API，不会阻塞主线程。
  • 劣势：
    • API 相对复杂，使用起来可能较为复杂，学习成本较高。
    • 不支持所有浏览器，需要考虑兼容性问题。

4. Web SQL Database

WebSQL(已于 2010 年 9 月 18 日起弃用)

  • 优势：

    • 提供 SQL 数据库的操作方式，适用于复杂的数据操作。

  • 劣势：

    • 已被废弃，不被推荐使用，不支持所有浏览器。

5. Cache

当你在网站上浏览页面时，浏览器会下载许多资源，例如 HTML、CSS、JavaScript 文件和图像。为了提高网页加载速度和降低网络流量，浏览器使用缓存来存储这些资源，以便在将来的页面访问中能够更快地获取它们。而 Cache API 就是一种 Web API，使开发者能够更精细地控制缓存的行为，从而提供更好的性能和用户体验。

首先对于常见的几种Cache相关的专业词汇做一个区分

  • cache 是浏览器提供的一种缓存机制，用于存储资源。
  • CacheStorage 是 Cache API 中的一个对象，用于管理命名缓存的集合。
  • Cache API 是用于控制和管理缓存的浏览器 API，其中核心是 Cache 对象，用于存储和管理特定类型的响应数据。

使用场景

其实基本所有的使用场景都是为了去提高性能和用户体验，一般情况下我们作缓存也主要是为了这些。

  1. 静态资源缓存： 将网站的静态资源(例如 CSS、JavaScript、图片等)缓存起来，以便在用户再次访问时能够更快地加载页面。
  2. 离线访问： 使用 Cache API 可以缓存应用程序的核心资源，使用户在离线状态下仍然能够访问内容，提供更好的离线体验。
  3. Service Worker 缓存： Service Worker 是一种运行在浏览器后台的脚本，可以拦截网络请求并将其缓存起来，从而实现更高级的缓存控制和离线功能。
  4. 数据预取和预加载： 在用户访问页面之前，提前缓存可能需要的资源，以减少页面加载时间。
  5. 动态内容缓存： 缓存 API 还可以用于缓存动态生成的内容，如 API 响应，以减轻服务器负担并提高响应速度。
  6. 减少网络请求： 缓存 API 可以减少重复的网络请求，从而降低服务器压力，提高性能。
  7. 图片懒加载： 缓存 API 可以用于懒加载图片，即只在用户需要时才加载图片资源，从而节省带宽和提高页面加载速度。
  8. 数据更新与刷新策略： 缓存 API 可以用于实现数据更新和刷新策略，确保用户始终获取最新的数据。
  9. 资源预加载： 提前缓存可能需要的资源，以便在用户访问相关页面时能够更快地加载内容。
  10. 响应速度优化： 缓存可以显著提高页面加载速度，从而改善用户体验和 SEO。

优劣：

  • 优势：

    • 适用于缓存资源，如图片、样式等，提高性能。
    • 可以灵活控制缓存过程，支持更复杂的缓存策略。

  • 劣势：

    • 主要用于缓存资源，不适合存储业务数据。

6. Redux、VueX、MobX、Pinia 等状态管理库

这个在网上有很多资料大家也相对比较熟悉，如果展开讲又能写好几篇文章，所以这边暂不展开讲了，如果有需要的可以看看快速入门Pinia

  • 优势：

    • 适用于大型应用，用于管理全局状态。
    • 可以跨组件共享状态，方便数据管理和更新。

  • 劣势：

    • 不适合存储大量非全局的数据。
    • 使用时需要引入额外的库和概念。

选择适当的储存方案取决于应用的需求。如果只需要存储少量数据，可以使用 Cookies、localStorage 或 sessionStorage。如果需要存储大量数据或进行复杂的数据操作，可以考虑 IndexedDB。如果需要全局状态管理，可以使用状态管理库。在选择时，还需考虑浏览器兼容性、数据安全性等因素。

基本储存的用法

1. Cookie

服务端在收到HTTP请求后，会在响应标头里添加一个或者多个Set-Cookie选项。当浏览器收到响应后就会保存下Cookie了，并将其放在HTTP的Cookie标头中(当存在多个时用;分割)，向统一服务器发送请求时一起发出。(此处可以设置过期日期或者时间段)

// Cookie格式 Cookie: yummy_cookie=choco; tasty_cookie=strawberry Cookie: <cookie-name>=<cookie-value>

生命周期

  • 会话期 Cookie 会在当前的会话结束之后删除。因为是浏览器定义了“当前会话”结束的时间，有一些浏览器在重启时会使用会话恢复。这可能导致会话 cookie 无限延长。
  • 持久性 Cookie 在过期时间(Expires)指定的日期或有效期(Max-Age)指定的一段时间后被删除。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

备注： 当 Cookie 的过期时间( Expires)被设定时，设定的日期和时间只与客户端相关，而不是服务端。这将会导致当用户修改了电脑的时间时可能会影响Cookie的过期时间，另外，由于服务端无法直接控制客户端的时间，所以 Cookie 的过期时间只能作为一种简单的机制来实现在客户端浏览器中的数据过期和失效。

发送位置

Domain 和 Path 标识定义了 Cookie 的作用域：即允许 Cookie 应该发送给哪些 URL。

  • Domain 属性

    Domain 指定了哪些主机可以接受 Cookie。如果不指定，该属性默认为同一 host设置 cookie，不包含子域名。如果指定了 Domain，则一般包含子域名。所以一般情况下我们都会选择指定Domain。

    例如，如果设置 Domain=mozilla.org，则 Cookie 也包含在子域名中(如 developer.mozilla.org)。

  • Path 属性

    Path 属性指定了一个 URL 路径，该 URL 路径必须存在于请求的 URL 中，以便发送 Cookie 标头。以字符 %x2F (“/”) 作为路径分隔符，并且子路径也会被匹配。

    例如，设置 Path=/docs，则以下地址都会匹配：

    • /docs
    • /docs/
    • /docs/Web/
    • /docs/Web/HTTP

    但是这些请求路径不会匹配以下地址：

    • /
    • /docsets
    • /fr/docs

  • SameSite 属性

    SameSite 属性允许服务器指定是否/何时通过跨站点请求发送(其中站点由注册的域和方案定义：http 或 https)。这提供了一些针对跨站点请求伪造攻击(CSRF)的保护。它采用三个可能的值：Strict、Lax 和 None。

    使用 Strict，cookie 仅发送到它来源的站点。Lax 与 Strict 相似，只是在用户导航到 cookie 的源站点时发送 cookie。例如，通过跟踪来自外部站点的链接。None 指定浏览器会在同站请求和跨站请求下继续发送 cookie，但仅在安全的上下文中(即，如果 SameSite=None，且还必须设置 Secure 属性)。如果没有设置 SameSite 属性，则将 cookie 视为 Lax。

JavaScript中的使用

通过 Document.cookie属性可创建新的 Cookie。如果未设置 HttpOnly 标记，你也可以从 JavaScript 访问现有的 Cookie。

javascript document.cookie = "yummy_cookie=choco"; document.cookie = "tasty_cookie=strawberry"; console.log(document.cookie); // logs "yummy_cookie=choco; tasty_cookie=strawberry"

通过 JavaScript 创建的 Cookie 不能包含 HttpOnly 标志。

请留意安全隐患问题，JavaScript 可以通过跨站脚本攻击(XSS)的方式来窃取 Cookie。

2. Storage

储存的方式为键值对。

2.1 LocalStorage

使用方式：

javascript // 添加 localStorage.setItem("myCat", "Tom"); // 读取 let cat = localStorage.getItem("myCat"); // 移除 localStorage.removeItem("myCat"); // 清除所有clear localStorage.clear();

当然你也可以这样使用

javascript localStorage.colorSetting = "#a4509b"; localStorage["colorSetting"] = "#a4509b";

2.2 SessionStorage

与2.1相同，替换localStorage为sessionStorage即可。

3. IndexedDB

基本使用流程

IndexedDB 鼓励使用的基本模式如下所示：

  1. 打开数据库。
  2. 在数据库中创建一个对象存储(object store)。
  3. 启动事务，并发送一个请求来执行一些数据库操作，如添加或获取数据等。
  4. 通过监听正确类型的 DOM 事件以等待操作完成。
  5. 对结果进行一些操作(可以在 request 对象中找到)

主要API

  • 数据库：IDBDatabase 对象，数据库有版本概念，同一时刻只能有一个版本，每个域名可以建多个数据库
  • 对象仓库：IDBObjectStore 对象，类似于关系型数据库的表格
  • 索引： IDBIndex 对象，可以在对象仓库中，为不同的属性建立索引，主键建立默认索引
  • 事务： IDBTransaction 对象，增删改查都需要通过事务来完成，事务对象提供了error,abord,complete三个回调方法，监听操作结果
  • 操作请求：IDBRequest 对象
  • 指针： IDBCursor 对象
  • 主键集合：IDBKeyRange 对象，主键是默认建立索引的属性，可以取当前层级的某个属性，也可以指定下一层对象的属性，还可以是一个递增的整数

数据库对比解析

为了让大家对IndexedDB的结构能够了解的更加清晰，这边使用MySQL说发来说明IndexedDB内各种数据的维度

图中一共是四个方框从第二个框开始分别是

  1. 库维度
  2. 表维度
  3. 字段维度

image.png

但是我们都一道一句话叫做JS万物皆对象所以在这里也不例外，表维度中储存的实际上是key-value对象，其value值实际是就是一个对象，字段就是该对象内的属性

image.png

使用示例

包含了基本的增删改查的方式，自己去尝试写了才知道他所谓的劣势，确实用起来比较麻烦，而且需要自己去做很多封装后使用起来才能够方便。可能这个就是IndexedDB的劣势，并且它的API有很多，这里只是介绍了基本使用的一部分。

有兴趣可以自己去MDN或者参考文献中的文章看。

```javascript const dbName = 'myDatabase'; const storeName = 'myObjectStore';

// 打开或创建数据库 const request = indexedDB.open(dbName, 1); // 该事件仅在最新的浏览器中实现，仅在新数据库或新版本号时触发，onupgradeneeded是唯一可以修改数据库结构的地方！ request.onupgradeneeded = event => { const db = event.target.result;

// 创建对象存储空间 const objectStore = db.createObjectStore(storeName, { keyPath: 'id', autoIncrement: true });

// 创建索引 objectStore.createIndex('nameIndex', 'name', { unique: false }); };

request.onsuccess = event => { const db = event.target.result;

// 添加数据 function addData(name, age) { // 打开事务 const transaction = db.transaction(storeName, 'readwrite'); // 指定store const objectStore = transaction.objectStore(storeName);

const newItem = { name, age };
const addRequest = objectStore.add(newItem);

addRequest.onsuccess = () => {
  console.log('【ADD】Data added successfully');
};

}

// 删除数据 function deleteData(id) { const transaction = db.transaction(storeName, 'readwrite'); const objectStore = transaction.objectStore(storeName);

const deleteRequest = objectStore.delete(id);

deleteRequest.onsuccess = () => {
  console.log('【DELETE】Data deleted successfully');
};

}

// 更新数据 function updateData(id, newData) { const transaction = db.transaction(storeName, 'readwrite'); const objectStore = transaction.objectStore(storeName);

const getRequest = objectStore.get(id);

getRequest.onsuccess = () => {
  const data = getRequest.result;

  if (data) {
    const updatedData = { ...data, ...newData };
    const updateRequest = objectStore.put(updatedData);

    updateRequest.onsuccess = () => {
      console.log('【UPDATE】Data updated successfully');
    };
  }
};

}

// 查询数据 function fetchData() { const transaction = db.transaction(storeName, 'readonly'); const objectStore = transaction.objectStore(storeName);

const data = [];
const cursorRequest = objectStore.openCursor();

cursorRequest.onsuccess = event => {
  const cursor = event.target.result;
  if (cursor) {
    data.push(cursor.value);
    cursor.continue();
  } else {
    console.log('Fetched data:', data);
  }
};

}

// 添加示例数据 addData('Alice', 25); addData('Bob', 30);

// 删除示例数据 deleteData(1);

// 更新示例数据 updateData(2, { age: 31 });

// 查询所有数据 fetchData();

// 关闭数据库连接 db.close(); };

request.onerror = event => { console.error('Database error:', event.target.error); }; ```

前面有提到过只有在onupgradeneeded方法中才能够修改库的数据结构，以下是获取原有的store进行数据结构修改的示例。注意：仓库升级之后无法看到之前的数据(会合并数据)，如果你想两个版本的数据都保留的话，需要在修改数据结构时新建仓库来储存上一个版本的数据。

```javascript // 升级数据库版本 const request = indexedDB.open(dbName, 2);

request.onupgradeneeded = event => {

// 获取原有 const objectStore = event.target.transaction.objectStore(storeName);

// 创建索引 objectStore.createIndex('phoneIndex', 'phone', { unique: true }); };

// 保留两份数据

request.onupgradeneeded = function(event) { const db = event.target.result;

// 创建一个临时的对象仓库用于存储旧版本数据 const tempStore = db.createObjectStore('tempStore');

// 获取旧版本的对象仓库 const oldUsersStore = event.target.transaction.objectStore('users');

// 遍历旧版本的数据，并将其复制到临时对象仓库中 oldUsersStore.openCursor().onsuccess = function(event) { const cursor = event.target.result; if (cursor) { tempStore.add(cursor.value); cursor.continue(); } }; }; ```

库推荐

既然他的劣势主要是在不易使用等，主要是自己使用起来麻烦，我们就需要踩在巨人的肩膀上。这里为大家来介绍一个巨人Dexie.js

Dexie.js 主要用途有：

  1. 简化 IndexedDB 操作： IndexedDB 是一个强大但相对复杂的浏览器本地数据库，使用原生 IndexedDB 进行操作可能较为繁琐。Dexie.js 提供了更简洁的 API，封装了复杂的操作，使得数据库的创建、数据的增删改查等操作变得更加友好。
  2. Promise 支持： Dexie.js 使用 Promises 来处理异步操作，这样可以更好地管理数据操作流程，避免回调地狱。
  3. 版本管理： Dexie.js 允许你定义数据库的版本和结构，使得数据库的升级和迁移变得更加容易。
  4. 支持查询： Dexie.js 提供了强大的查询功能，可以方便地进行数据的筛选和检索。
  5. 跨浏览器兼容性： Dexie.js 能够在现代浏览器以及 IE 等旧版本的浏览器中运行，保证了跨浏览器的兼容性。

总之，Dexie.js 是一种简化 IndexedDB 操作的工具库，适用于需要在前端进行本地数据存储和操作的场景，如离线应用、浏览器扩展等。它使得使用 IndexedDB 变得更加容易，并且提供了一种更加现代和清晰的编程方式。

4. Cache API

因为会有兼容性问题所以建议使用之前先看看浏览器是否支持，不支持就只能寻求其他方案了。

javascript const useCache = 'caches' in window;

Cache常用方法

  • .add() 接受URL作为参数，返回promise，只响应status为200范围内的响应
  • .addAll() 接受URL数组作为参数，返回promise
  • .put() 接受一个键值对作为参数，返回promise
  • .delete() 接受一个URL作为删除的参数，返回promise
  • .keys() 返回一个解析为 Cache 键数组的 Promise
  • .match() 接受一个对象或者URL，返回第一个匹配请求的 Response 对象，如果没有匹配到，则解析到 undefined
  • .matchAll() 类似于addAll

使用方法

```javascript // 打开一个命名为 "my-cache" 的缓存, 如果没有则会新建 caches.open('my-cache').then(cache => { // 将 URL 为 "https://example.com/data" 的响应添加到缓存中 cache.add('https://example.com/data'); });

// 在 fetch 事件中，先从缓存中查找响应，如果缓存中没有，则发起网络请求并缓存响应 self.addEventListener('fetch', event => { event.respondWith( caches.match(event.request).then(response => { // 如果在缓存中找到了响应，则返回缓存的响应 if (response) { return response; }

// 否则，发起网络请求并缓存响应
  return fetch(event.request).then(response => {
    // 克隆响应，因为响应是只能使用一次的对象
    const responseToCache = response.clone();

    // 将响应添加到缓存中
    caches.open('my-cache').then(cache => {
      cache.put(event.request, responseToCache);
    });
    return response;
  });
})

); });

// 删除名为 "my-cache" 的缓存 caches.delete('my-cache'); ```

江子麟
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
前端本地存储方案-localForage
jojo1001的博客
05-10 2206
localForage 是前端本地存储的库，支持多种存储后端，并提供了一致的API来存储和检索数据，遵循“渐进增强”或“优雅降级”的原则。
前端HTML5几种存储方式的总结
weixin_33694172的博客
07-24 573
接下来要好好总结一些知识，秋招来啦。。。虽然有好多知识都不大会，但是还是要努力一下，运气这种东西，谁知道呢~ 总体情况 h5之前，存储主要是用cookies。cookies缺点有在请求头上带着数据，大小是4k之内。主Domain污染。 主要应用：购物车、客户登录 对于IE浏览器有UserData，大小是64k,只有IE浏览器支持。 目标 解决4k的大小问题 解决请求头常带存...
前端数据存储方案集合（cookie localStorage等）以及详解 （二）
ankuailan3925的博客
08-04 226
前端数据存储方案集合（cookie localStorage等）以及详解 （二） 在之前的文章中已经介绍到了 前端存储方案中的 cookie 。 但是 cookie 的存储上限是 4KB。 如果超过了 4KB ，在获取cookie 的时候会返回空值。 那如果存储内容超过 4kb，我们该如何处理呢？ 这里我们将分别 介绍 几种前端存储方式： localStorage， sessionS...
前端数据存储方式
冲鸭^
08-28 3991
Cookie cookie 用于存储web页面的用户信息。 cookie 是一些数据，存储在你电脑上的文本文件中。当web服务器向浏览器发送web页面时，在连接关闭后，服务端不会记录用户的信息。Cookie的作用就是用于解决如何记录客户端的用户信息。 当用户访问web页面时，他的名字记录在cookie中。 在用户下一次访问该页面时，可以再cookie中读取用户的访问记录。 Cookie...
前端页面存取数据
weixin_33805557的博客
05-16 297
如果使用本地存储如：cookie，localStorage，sessionStorage，Web SQL的情况下，前端存取数据非常容易。 本文介绍，不使用以上本地存储，只在页面（标签里面）上存取数据。 最简单的一种做法是隐藏表单或者隐藏元素都可以： <div style="dispaly:none" class="data">${后台穿过来的数据}</div> ...
万字长文解密苹果A12芯片
01-19
在过去的几年里，苹果的芯片设计团队一直处于架构设计和制造工艺的前沿。苹果A12是该公司又跨越代际的飞跃，因为它号称是首款商用7nm芯片。 　在谈论工艺节点时，一般而言，数字越小，晶体管就越小。...
数据治理怎么做？这篇万字长文终于讲清楚了!.docx
06-17
这篇万字长文终于讲清楚了!.docx数据治理怎么做？这篇万字长文终于讲清楚了!.docx数据治理怎么做？这篇万字长文终于讲清楚了!.docx数据治理怎么做？这篇万字长文终于讲清楚了!.docx数据治理怎么做？这篇万字长文终于...
万字长文+图文并茂+全面解析微前端框架 qiankun 源码 – qiankun 篇
01-08
本文将针对微前端框架 qiankun 的源码进行深入解析，在源码讲解之前，我们先来了解一下什么是 微前端。 微前端 是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变...
万字长文详解大数据流式计算框架 Flink 实战（中篇）1
08-03
引入Kafka(https://blog.csdn.net/zpcandzhj/article/details/108770504)连接器pom依赖，连接器的版
前端开发中常用的存储方法（带解析）
我们好像在哪见过
07-13 2250
前端存储是指在浏览器端存储数据的方法。以下是一些常见的前端存储方法及其详细介绍和解析：
前端数据存储
liushuxin1221的博客
08-31 1489
前端数据存储
前端存储的方式
qq_46615920的博客
08-22 285
一、本地存储和cookie的区别 本地存储的特点： 存储量限制（5M） 客户端完成，不会请求服务器处理 sessionStorage数据是不共享 localStorage共享 cookie特性： 同一个网站中所有页面共享一套cookie 数量、大小有限（大小4KB） 过期时间 cookie是随HTTP事务一起被发送给服务器 二、本地存储的分类 HTML本地存储提供了两个在客户端存储数据的对象 ①. window.localStorage – 存储没有截止日期的数据 ②. window.sessionSt
Web/前端存储简述
qq_57126801的博客
08-31 452
Web/前端存储简述
前端存储方案
最新发布
m0_59345890的博客
03-11 841
这三个浏览器兼容性最高的三种前端储存方案。
4种前端本地存储方法 在浏览器中持久化保存数据
不想被卷出去的前端老鸟
07-02 9650
4种前端本地存储方法 在浏览器中持久化保存数据
前端之存储数据方法
weixin_53105591的博客
01-29 662
前端数据存储方法
前端存储数据
weixin_45490637的博客
09-30 2011
前端常用的存储数据的方式
前端有几种存储方式？
weixin_47450807的博客
04-16 6182
一、写在前面 前端的存储方式也是重中之重，下面来总结一下前端存储方式的种类。 二、总结 主要存在四种：cookie,localStorage,sessionStorage,indexedDB。 2.1、cookies： 在HTML5标准前本地储存的主要⽅式，优点是兼容性好，请求头⾃带cookie⽅便，缺点是⼤⼩只有4k，⾃动请求头加⼊cookie浪费流量，每个domain限制20个cookie，使⽤起来麻烦需要⾃⾏封装。 2.2、localStorage：HTML5加⼊的以键值对(Key-Value)为标准
前端存储方式总结
qq_42874319的博客
07-15 1128
前端存储方式总结 1. Cookie存储 Cookie诞生之初的作用就是解决HTTP的无状态请求，用来记录一些用户相关的一些状态。 Cookie是一小段文本信息，伴随着用户请求在 Web 服务器和浏览器之间传递，其大小限制在4k左右（不同浏览器略有不同）。 1.1 Cookie的格式 因为浏览器提供了 cookie 属性给 JavaScript，所以可以通过 document.cookie 来访问这个页面中的cookie。 这是一串字符串，仔细观察，我们可以发现规律。每个 cookie 都以名/值对的形式
【万字长文】mysql多数据源完整教程
11-03
MySQL多数据源是指在一个应用程序中同时使用多个不同的MySQL数据库来存储和管理数据的技术。它可以帮助开发人员更灵活地处理各种数据库操作，提高程序的性能和可扩展性。下面是一个完整的MySQL多数据源教程。 一、设置数据库连接信息 1. 在应用程序的配置文件中，创建多个数据库连接的配置项。例如，可以为每个数据源创建一个配置项，分别命名为db1、db2等。 2. 在配置项中，设置每个数据源的连接信息，包括数据库地址、用户名、密码等。 二、创建数据源管理器 1. 创建一个数据源管理器类，用于管理多个数据源。该类需要实现数据源的动态切换和获取。 2. 使用Java的线程安全的数据结构，如ConcurrentHashMap来存储数据源信息。将配置文件中的数据库连接信息加载到数据结构中。 3. 实现方法来切换不同的数据源，通过传入数据源的名称来切换到对应的数据库。 三、实现数据源切换 1. 在应用程序中，根据业务需求选择需要使用的数据源。可以通过调用数据源管理器的方法来切换数据源。 2. 在DAO层的代码中，根据当前使用的数据源名称，选择对应的数据源进行数据库操作。 四、使用多数据源进行数据库操作 1. 在DAO层的代码中，区分不同的数据源，并将数据库操作的代码包装在对应的数据源中。 2. 在业务层的代码中，调用DAO层的方法来进行数据库操作。不同的数据源会自动切换。 五、处理事务 1. 如果需要在一个事务中操作多个数据源，可以使用分布式事务的方式来处理。 2. 可以使用开源的分布式事务框架，如Atomikos、Bitronix等来实现多数据源的事务管理。 六、监控和维护 1. 使用监控工具来监控多个数据源的使用情况，包括连接数、查询次数等。 2. 定期对数据库进行维护，包括索引优化、数据清理等工作，以保证数据库的性能和稳定性。 通过以上步骤，我们可以实现MySQL多数据源的配置和使用。使用多数据源可以更好地管理和处理不同的数据库操作，在提高程序性能和可扩展性的同时，也提供了更灵活的数据操作方式。同时，需要注意合理选择和配置数据源，以及监控和维护数据库，以保证系统的运行效率和数据的安全性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值